Bonita Montero <Bonita.Montero@gmail.com>: Aug 29 04:48PM +0200
If you throw a system_error with system_category and a platform-specific
error code as an integer the error-code is translated by the runtime to
a platform-specific error string. I think under Windows FormatMessage()
is used and under Unix strerror() is used(). This translation is done
by the error_cateogy-subclass you supply while throwing the error.
Unfortunately under Windows this error string isn't localized. So I
wrote my own error_cagegory subclass for Win32 and Unix:
// xsystem_category.h
#pragma once
#include <system_error>
struct xsystem_category : public std::error_category
{
xsystem_category() = default;
xsystem_category( xsystem_category const & ) = delete;
virtual ~xsystem_category() override = default;
void operator =( xsystem_category const & ) = delete;
virtual char const *name() const noexcept override;
virtual std::error_condition default_error_condition( int code ) const
noexcept override;
virtual bool equivalent( int code, std::error_condition const
&condition ) const noexcept override;
virtual bool equivalent( std::error_code const &code, int condition )
const noexcept override;
virtual std::string message( int condition ) const override;
};
// xsystem_category.cpp
#if defined(_WIN32)
#include <Windows.h>
#elif defined(__unix__)
#include <string.h>
#include <locale.h>
olcott <NoOne@NoWhere.com>: Aug 28 02:47PM -0500
Since Turing machines are mathematical objects that only exist in the
mind people can have contradictory thus incoherent ideas about these
abstract mathematical objects and never realize that their ideas are
incoherent.
When we study the theory of computation using physically existing
machines such as the x86 architecture then the incoherent abstract ideas
are shown to be incoherent in that they cannot be physically implemented.
void Px(ptr x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H(Px, Px));
}
If a decider must always return a value whenever it is called this
requires H to return a value to Px even though H is called in infinite
recursion.
This even requires that the function call from Px to H(Px,Px) must
return a value to Px even if this function call to H is not even
executed. In the physical model of computation it is an axiom the
programs that are not executed never return values because it is
physically impossible.
When simulating halt decider H sees that Px is about to call H(Px,Px) in
infinite recursion H aborts its simulation of Px before this call is
executed.
*Clearly computer science is incorrect on this point*
Computer science says that H must still return a value to Px even though
the call to H is not even executed because all deciders must ALWAYS
return to their caller.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Aug 28 06:58PM +0200
Is there *any* scenario how this error can happen without any
constructor or destructor in the call stack?
Marcel
| Richard Damon <Richard@Damon-Family.org>: Aug 28 01:12PM -0400
On 8/28/22 12:58 PM, Marcel Mueller wrote:
> Is there *any* scenario how this error can happen without any
> constructor or destructor in the call stack?
> Marcel
I can see it happening with threads (the constructor/destructor is in a
different Thread).
Not sure if there is any way to create or slice an object to result in
an "abstract" object.
| Paavo Helde <eesnimi@osa.pri.ee>: Aug 28 08:37PM +0300
28.08.2022 19:58 Marcel Mueller kirjutas:
> Is there *any* scenario how this error can happen without any
> constructor or destructor in the call stack?
Sure, when you call via an invalid pointer where the object has been
already destroyed.
| Lynn McGuire <lynnmcguire5@gmail.com>: Aug 27 10:40PM -0500
On 8/27/2022 5:24 PM, Thomas Koenig wrote:
>> subtracted from first: x--; *(x+i);.
> That's an f2c idiom, which is not valid C, AFAIK, because
> the pointer would point before the actual array.
While the second pointer is a bad pointer, it is not a illegal pointer.
Variables can point to anywhere, they are not illegal until referenced.
Otherwise, code would be crashing all over the place. If I malloc'd
some space, then free'd the space, and did not NULL the pointer, that
dangling pointer would crash if ever referenced (hopefully) but not if
it just hangs around.
I wish that C/C++ would provide some sort of pointer validation but it
does not. I keep track of my pointers for that reason and validate them
before using when I have some error prone code. In 850,000 lines of F77
and 30,000 lines of C/C++ code, I have suspicious pointers in several
areas due to programmers suballocating malloc'd space and forgetting to
nullify those suballocated pointers after freeing the allocated space.
Old code, you gotta love it.
Lynn
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 27 10:07PM -0700
> I malloc'd some space, then free'd the space, and did not NULL the
> pointer, that dangling pointer would crash if ever referenced
> (hopefully) but not if it just hangs around.
Computing a pointer before the beginning of an array causes undefined
behavior in C and C++, even if you never dereference it.
[...]
--
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 */
| Thomas Koenig <tkoenig@netcologne.de>: Aug 28 07:50AM
>> the pointer would point before the actual array.
> While the second pointer is a bad pointer, it is not a illegal pointer.
> Variables can point to anywhere, they are not illegal until referenced.
Unfortunately not.
Looking at n2596.pdf, one finds under J.2, "Undefined behavior",
— Addition or subtraction of a pointer into, or just beyond,
an array object and an integer type produces a result that does
not point into, or just beyond, the same array object (6.5.6).
> Otherwise, code would be crashing all over the place.
Undefined behavior does not mean that the code will reliably crash.
It just says that the C standard gives no guarantee about what will
happen, and, even if it works right now, such code is at the mercy
of future compiler revisions, cosmic rays, and other forseen and
unforseen circumstances.
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Aug 28 10:01AM +0200
Op 27.aug..2022 om 22:01 schreef Lynn McGuire:
> Yup. So Fortran x(i) is equivalent to *(x+i-1). Or, the x is
> subtracted from first: x--; *(x+i);.
> Lynn
I don't understand the idea of x--. Why modifying x? What happens if x
is indexed later again?
| Thomas Koenig <tkoenig@netcologne.de>: Aug 28 08:14AM
>> Lynn
> I don't understand the idea of x--. Why modifying x? What happens if x
> is indexed later again?
The idea is to use this modified pointer for one-based array
accesses, so that it would be possible to translate Fortran's A(1)
into a[1] on the C side, or A(N) into a[n].
The correct way to do this according to the C standard would be to
translate A(N) into a[n-1] on the C side. There are several reasons
why this might not have been done: Readability of the generated
code (although f2c code is already hard to read), because it made
the code slower with compilers of the day, and probably because it
"just worked" with the compilers.
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 28 11:07AM +0200
Am 26.08.2022 um 22:49 schrieb Lynn McGuire:
> My Fortran starts at one. My C++ starts at zero. This has made my life
> hell.
> Lynn
On the CPU-level you heave the least number of calculations to
determine an address of an indexed entity if the index starts
at zero.
| David Brown <david.brown@hesbynett.no>: Aug 28 11:52AM +0200
On 28/08/2022 09:50, Thomas Koenig wrote:
> happen, and, even if it works right now, such code is at the mercy
> of future compiler revisions, cosmic rays, and other forseen and
> unforseen circumstances.
Indeed.
C was designed to have as few restrictions on the hardware as it could,
while still having a minimum feature set. If you have a segmented
memory architecture (such as x86), then addresses might have a form
"segment:offset". If an array starts at offset 0, what does it mean to
have an address one before that? It might make no sense, or have
different meanings in different contexts, or require inefficient extra
instructions to get right. Some architectures pre-load information
about memory pages or segments when a pointer register is loaded,
causing trouble if it does not actually point to valid memory. Leaving
this all undefined is much simpler for everyone.
(The other end, one past the end of the array, is too useful in common C
idioms to leave undefined - even if it might mean that an implementation
can't use the last address in memory.)
| Paavo Helde <eesnimi@osa.pri.ee>: Aug 28 07:43PM +0300
28.08.2022 06:40 Lynn McGuire kirjutas:
>> That's an f2c idiom, which is not valid C, AFAIK, because
>> the pointer would point before the actual array.
> While the second pointer is a bad pointer, it is not a illegal pointer.
The C++ standard (n4861) calls this "an invalid pointer value".
For pointers which continue to point to freed objects, it says "A
pointer value becomes invalid when the storage it denotes reaches the
end of its storage duration".
About invalid pointers it says:
"Indirection through an invalid pointer value and passing an invalid
pointer value to a deallocation function have undefined behavior. Any
other use of an invalid pointer value has implementation-defined behavior."
There is also a footnote:
"Some implementations might define that copying an invalid pointer value
causes a system-generated runtime fault."
So, while technically one might get away with the "x--" trick most of
the time with the linear memory addressing used by mainstream
implementations nowadays, still various diagnostic tools would mark
these as invalid pointers, causing an avalanche of errors whenever you
want to solve your actual memory access problems.
I guess it might also subvert automatic garbage collection which is
sometimes used with C++. There is a special case of "safely-derived"
pointer values which I suspect is made exactly for making GC possible,
and changing the pointer value to x-1 would apparently ruin this.
And with segmented memory, like with 16-bit x86, it might cause all kind
of surprises.
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 28 11:49AM +0200
template<std::input_iterator CharInputIt, typename Callback>
requires std::is_integral_v<std::iter_value_t<CharInputIt>>
&& requires( Callback callback, CharInputIt cri ) { { callback( cri,
cri ) }; }
void linify( CharInputIt begin, CharInputIt end, Callback callback )
{
CharInputIt
scn = begin,
lineBegin;
if( scn == end ) [[unlikely]]
return;
auto checkedCallback = [&]() { if( lineBegin != scn ) callback(
lineBegin, scn ); };
for( ; ; )
for( lineBegin = scn; ; ++scn )
if( *scn == '\n' ) [[unlikely]]
{
checkedCallback();
if( ++scn == end )
return;
break;
}
else if( *scn == '\r' ) [[unlikely]]
{
checkedCallback();
if( ++scn == end || *scn == '\n' && ++scn == end )
return;
break;
}
}
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 27 11:15PM -0700
On 8/8/2022 9:43 AM, Alan Beck wrote:
> Shouod I be learing C,C++ or Arduino "sketch" language.
> I have books for all three.l
> Thand beforo hand
To C or not to C... Well, actually, I just might have to design a plugin
interface and I would want C bindings. An end user can program a plugin
in C, C++, C#, ect... I just need to design the C API and
data-structures. So, I choose to use C for the raw plugin logic API.
| David Brown <david.brown@hesbynett.no>: Aug 28 11:30AM +0200
On 27/08/2022 18:44, Manfred wrote:
> 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.
|
Sam <sam@email-scan.com>: Aug 25 07:39PM -0400
JiiPee writes:
> Yes. When the classes cannot much communicate, and then the other class
> deletes that pointer... then my class somehow needs to be sure its still
> valid.
If the "other class deletes that pointer", then the other class must
directly, or indirectly, make provisions for that. Nothing in C++ happens
automatically, by magic.
> buttons. But how can this manager know if the button still exists... and
> that was the issue. I was just wondering is its poissible without changing
> code around the class.
If there's something that called a "button group manager", that's
responsible for managing these "buttons", but this manager isn't the one
that's creating these buttons, then there must be some formal process by
which thus "button group manager" must become aware of these buttons,
somehow. That also doesn't happen automatically, by magic. There must be
some procedure by which these buttons get handed over to this "button group
manager".
Therefore, there must also be a procedure by which this "button group
manager" must be notified that a particular button should no longer be under
its control. So, whatever this process or procedure is, it needs to be used
before deleting this button, so that the "button group manager" does not use
a pointer to a deleted object.
The End.
| Manfred <noname@add.invalid>: Aug 26 02:26AM +0200
On 8/24/2022 8:59 PM, Keith Thompson wrote:
> Most C++ compilers aren't fully conforming by default. Any conforming
> C++ implementation must diagnose `void main()` (and may then either
> accept it or reject it).
Curiously, the C standard poses no requirements on main() for
freestanding implementations.
Apparently the C++ standard does instead: it says that main() may not be
present in a freestanding implementation, but, as it is written, if it
is present then it must have int return type.
| Paul N <gw7rib@aol.com>: Aug 26 05:49AM -0700
On Thursday, August 25, 2022 at 3:29:09 PM UTC+1, JiiPee wrote:
> existing buttons. But how can this manager know if the button still
> exists... and that was the issue. I was just wondering is its poissible
> without changing code around the class.
Can't you make it that only the manager can delete buttons? That way the manager will always know what buttons are there and which are not. It seems a reasonable responsibility for a "manager" to have. Other parts of the program can request the manager to delete a button, but they don't actually do it themselves.
| JiiPee <kerrttuPoistaTama11@gmail.com>: Aug 26 07:35PM +0300
On 26/08/2022 15:49, Paul N wrote:
> Can't you make it that only the manager can delete buttons?
Not really, because I cannot really touch much the existing code....
that would require re-testing etc.... so its not so easy.
| Louis Krupp <lkrupp@invalid.pssw.com.invalid>: Aug 26 12:25PM -0600
On 8/26/2022 10:35 AM, JiiPee wrote:
>> Can't you make it that only the manager can delete buttons?
> Not really, because I cannot really touch much the existing code....
> that would require re-testing etc.... so its not so easy.
Could you create an intermediate subclass of Parent that would add the
required functionality?
A crude outline:
===
class Parent // can't be modified
{
public:
void foo2() {}
};
class Nanny : public Parent
{
public:
Nanny(Parent* parentptr, Child* childptr) : Parent(parentptr); //
keep list of children
~Nanny(); // notify children of nanny's impending deletion by
calling Child::nanny_byebye
}
class Child
{
public:
Nanny* m_nanny{nullptr, this}; // add child to list
void nanny_byebye() {
m_nanny = nullptr;
}
void foo() {
// check to see if nanny has been deleted
if (m_nanny) m_nanny->foo2();
}
};
void main()
{
Parent* nanny = new Nanny;
Child child;
child.m_nanny = nanny;
delete nanny;
child.foo(); // Nanny::foo2 won't be called
}
===
Louis
| Manfred <noname@add.invalid>: Aug 26 01:59AM +0200
On 8/25/2022 7:11 PM, JiiPee wrote:
> }
> };
> Can anybody suggest this to Bjarne? hehe
I don't think this would be a good idea ("selective" friendship, not
contacting Bjarne..)
- friend by itself should be used parsimoniously: it goes against
encapsulation, so more often than not it is a symptom of poor design
(exceptions apply, but they are in fact exceptions)
- "selective" friendship, in the way you are suggesting, breaks
encapsulation even more, in that it introduces a new level of its
fragmentation.
Others have given solutions that do what you are trying to do.
If I had to address this issue, I'd look for a different and possibly
more consistent design, e.g. simply:
class Parent_public
{
public:
void foo();
};
class Parent : public Parent_public
{
private:
void foo2();
};
| JiiPee <kerrttuPoistaTama11@gmail.com>: Aug 26 07:19AM +0300
On 26/08/2022 02:59, Manfred wrote:
> private:
> void foo2();
> };
A good idea, and I might use this also. Although a small "problem" I see
here is that it complicates the code a little more (more layers and more
typing ).
This would be much shorter, what I suggested:
void foo2() { : friend Child
Only two words .
For me, I like it a little more if its less typing and more simple.
But ok, maybe there is a logical reason not to support selective
friendship. But I have been looking that feature to be honest many
times. Because I rarely need one class have FULL friendship. Almost
always the friendship needs to be only partial.. normally 1-2 funktions.
| JiiPee <kerrttuPoistaTama11@gmail.com>: Aug 26 07:25AM +0300
On 26/08/2022 02:59, Manfred wrote:
> - friend by itself should be used parsimoniously: it goes against
> encapsulation, so more often than not it is a symptom of poor design
> (exceptions apply, but they are in fact exceptions)
I also use rarely friends and its the last solution.
But... sometimes it is just easiest and most practical way, if the
classes are tightly linked with each others (like some kind of cache
class for another), and the classes go together "privately".
Also it keeps the code more simple. Instead of writing 20 new lines,
only 1-2 lines of code needed. So its kinda looking for a balance
between "best practices" and practicality/simple-short code.
But again, I only do it if no other easy solution and it has some logic
in it.
| Paavo Helde <eesnimi@osa.pri.ee>: Aug 26 12:13PM +0300
25.08.2022 20:11 JiiPee kirjutas:
> }
> };
> Can anybody suggest this to Bjarne? hehe
You mean the C++ committee, not Bjarne. And I think everybody agrees C++
has already too many features, so it would be hard to propose a new one,
especially related to things like friends which are kind of frown upon
anyway.
Meanwhile, what about this? Instead of a private function accessible to
all friends define a public function accessible only to a "privileged
friend":
class Child1;
class Child2;
class Child1Key {
friend class Child1;
Child1Key() {}
};
class Child2Key {
friend class Child2;
Child2Key() {}
};
class Parent {
public:
void foo(Child1Key key) {}
void foo2(Child2Key key) {}
};
class Child1 {
public:
Parent* m_parent{ nullptr }; // later initialized ...
void foo3() {
// Can access only foo()
m_parent->foo(Child1Key{}); // this is OK
// cannot access any other privates
m_parent->foo2(Child2Key{}); // this is NOT OK
}
};
| Michael S <already5chosen@yahoo.com>: Aug 26 03:55AM -0700
On Thursday, August 25, 2022 at 8:11:37 PM UTC+3, JiiPee wrote:
> }
> };
> Can anybody suggest this to Bjarne? hehe
When somebody is obsessed with encapsulation enforcement
tools (private/protected/friend etc) it's a sure sign of him
having too much time and too little real work to do.
If I was your boss I'd knew how to handle that.
| JiiPee <kerrttuPoistaTama11@gmail.com>: Aug 26 07:29PM +0300
On 26/08/2022 12:13, Paavo Helde wrote:
> m_parent->foo2(Child2Key{}); // this is NOT OK
> }
> };
Thanks. a nice trick. Yes this is one of the best ways. I ll definitely
keep this in my mind. I think I have seen the "key" pattern before, this
seems similar.
| Paavo Helde <eesnimi@osa.pri.ee>: Aug 26 08:49PM +0300
26.08.2022 19:29 JiiPee kirjutas:
> Thanks. a nice trick. Yes this is one of the best ways. I ll definitely
> keep this in my mind. I think I have seen the "key" pattern before, this
> seems similar.
Yes, but also bear in mind that these kind of tricks are most often a
sign of serious over-engineering. If the intent is that foo() should be
called only by Child1 then just name if FooForChild1() and be done with it.
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 26 12:33AM +0100
>> 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.
> 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.
> 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.
| Manfred <noname@add.invalid>: Aug 26 03:11AM +0200
On 8/25/2022 12:29 PM, Ben Bacarisse wrote:
> 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.
My take on this is that the academic idealist would be less bothered
with practical distractions like maintainability.
The idealist would code an algorithm just matching the theoretical
model, so if a boolean type is involved, type bool it is.
Your "purist" route also make sense, but more like the collector's focus
rather than the innovator impulse.
Using _Bool is clearly motivated by not breaking existing code, which is
a priority in most industry jobs, arguably less in an academic
environment where focus is more on researching new results rather than
maintaining existing products.
That said, I share your sentiment that keeping _Bool and staying on
<stdbool.h> would have been the correct thing to do.
The problem was solved, and solved well. No need to reopen and break it.
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Aug 25 07:56PM -0700
On Thursday, 25 August 2022 at 19:36:10 UTC+1, David Brown wrote:
> 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.
| David Brown <david.brown@hesbynett.no>: Aug 26 10:39AM +0200
On 26/08/2022 01:33, Ben Bacarisse wrote:
>> 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.
>> (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!
>> 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? :-)
| David Brown <david.brown@hesbynett.no>: Aug 26 10:47AM +0200
On 26/08/2022 04:56, Malcolm McLean wrote:
> 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.
> 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.
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Aug 26 02:48AM -0700
On Friday, 26 August 2022 at 09:47:36 UTC+1, David Brown wrote:
> 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.
> 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.
> 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".
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 26 10:57AM +0100
>>>>> 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.
| David Brown <david.brown@hesbynett.no>: Aug 26 12:49PM +0200
On 26/08/2022 11:57, Ben Bacarisse wrote:
> 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.
| David Brown <david.brown@hesbynett.no>: Aug 26 01:02PM +0200
On 26/08/2022 11:48, Malcolm McLean wrote:
> 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.
> 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.
> 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.
>> 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 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/.
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Aug 26 04:57AM -0700
On Friday, 26 August 2022 at 12:03:20 UTC+1, David Brown wrote:
> 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.
| David Brown <david.brown@hesbynett.no>: Aug 26 02:55PM +0200
On 26/08/2022 13:57, Malcolm McLean wrote:
> 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.
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Aug 26 06:20AM -0700
On Friday, 26 August 2022 at 13:55:38 UTC+1, David Brown wrote:
> 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++.
|
|
