“Rennie Allen” <email@example.com> wrote in message
Igor Kovalenko wrote:
You are treating the expression ‘application programming’ in such a wide
sense that it makes it useless (and in that sense in could indeed make
what we said ‘blanket statements’).
Sigh. I wouldn’t think we would need to discuss what constitutes
application code in qnx.rtos… but here goes…
First couple of definitions:
API - Application Programming Interface.
Product - A packaged entity produced by a programmer.
Application programming is what is done by programmers who make use of an
API to solve a problem in the domain of their product (which can not be
System programming is what is done by programmers who assemble a set of
unpublished interfaces to solve a problem in the domain of their product
(which is a published API).
Thanks for these revelations.
You may notice that the “pivot point” here is the concept referred to as
an API. If your product is an API you are a system programmer, if it
isn’t you are an application programmer. No further definition (or
restriction) of what an application programmer can and can’t do is
necessary. This definition is clean, robust and universally accepted (at
least I thought so, until now >
And if you’re writing a replacement for timer_* functions, then what is your
product may I ask? Would not that by chance be an API?
In the real world, application programmers write resource managers,
drivers, and scheduling algorithms (sometimes they find it necessary to
duplicate the functionality of one of the APIs they purchased).
I have been in the real world few times myself. Thanks one more time.
Application programmers are identified not by the classes of the software
entities they construct, but by the final product they deliver to their
customer (strangely enough you seem to espouse this very definition
Our interpretation of it is narrow -
‘application programming’ means writing client side code exclusively (as
opposed to writing drivers, servers, libraries or other system
I don’t know if it is narrow, but it is certainly wrong.
This reminds me of arguing with my wife. If I am saying something she does
not like, I am wrong. Evidently, by definition - since she does not provide
any arguments either.
Another way to make the distinction clear is by looking at
who is the customer of the code written by a particular developer. If
your customer is another programmer, then you’re NOT writing an
is system-level programming and our arguments against Msg* do not apply.
Since we apparently agree that a system programmer (and the act of system
programming) is identified by whether or not a new API is the product (not
by the class of software module that was written), then you have argued
successfully against your own position, since there is nothing in the OPs
post that indicates they intended to produce a new API as the final
product (thus by the usual definition of an application programmer, they
were in fact, acting as an AP when they wrote what you implied qualifies
them as a SP, and thus your “rules” that disqualify them from writing code
that uses Msg* don’t apply).
I was refering to your example, not to whatever ‘they’ are doing. You have
tried to use the example with relacing timer_* set as a justification for
using Msg* API in applications. I have countered that if you’re writing a
replacement for libc function, you’re not writing an application and your
example is invalid. Not sure how you missed this up to now, but I hope you
get it now that in the last few postings I was countering your example, not
advising the original poster on when use or not use Msg*. Although do I
realize now that I should not waste any more time doing so.
We can now move on by agreeing that John Nagle was right in the first
ps: if the second-to-last paragraph above is difficult to follow, it is
because it attempts to unravel the circular logic used in your arguments
(I tried hard to simplify it).
See above about my wife. If she did or said something silly, it is
inevitably ‘because I caused that’.