Windows API vs. UNIX shell (equiv?) -- Or -- When is a programming language a language and not a script?

Question

I've seen a number of question's closed as "Not programming related" (e.g. http://stackoverflow.com/questions/397854/what-process-accesses-my-hdd)

I understand that their's several alternative site (stackoverflow) themed-forums and to attempt keep site question's to a minimum also some may argue that this is too subjective, o well, I got madly flamed for my first answer, so here's my first question, I'll try to frame it in a psudo-contextual-basis (jepordy style) to keep some regulator's at bay...

Is it not fair to #include UNIX systems's level discussion in the same realm as programming? One of the most usefull UNIX tools I've ever used, strace/trus/par, is based around system call information and reporting, other tools like ltrace can do similar things for libararies...

System admin, I agree is not for this forum, like "How to I make qmail do X?", but is "My smtp virus scanner is not fast enough, based on dnotify?" (answer) "Hey, use inotify", so easy to discreminate? The latter may either be shell or linux kernel system call's.

I am not much of one for standards (read one too many lately), I'm adding a tag on POSIX "command language", to shift some focus on idenitfying some definative info.

Systems level interaction being somewhat of a programming-interface(API)/user-interface(shell) duality (perticularly for UNIX).

If the context of an inquisitor be primarially interface based and it is an easy quarry (or even typical) to solution an exclusivly programming/API responce, to help man and machiene alike, why require a domain change (body of knowledge or URL domain;)?

Answer 1

I'm sorry, I don't understand the distinction you appear to be trying to draw between UNIX and Windows. As someone who uses and programs both of them, the distinction about whether a call to a kernel service is in a library or not seems unimportant. The distinction is - is the call made in a programming context? For example, questions about the UNIX cat command do not, I suggest, belong here, whereas questions about the UNIX read() system call, which cat must use at some level, do.

Oh, and there is no "tight integration" between the kernel and the shell.

Answer 2

Is it not fair to #include UNIX systems's level discussion in the same realm as programming? One of the most usefull UNIX tools I've ever used, strace/trus/par, is based around system call information and reporting, other tools like ltrace can do similar things for libararies...

Discussion of debugging tools is perfectly valid on SO, IMO. I've not seen a debugging tools question closed.

So if the closed question you reference had been 'how do I find what processes are touching files for debugging my program', then I imagine it wouldn't have been closed. But it appeared to be 'how do I find what processes are touching files to improve the ambience of my bedroom', which isn't programming related.

Sysadmin questions belong elsewhere. Bash programming is programming related, system utilities aren't. It's just the same as 'how do I make Word format my document in three columns' isn't programming related, but 'how do I program a VB script to format my Word document' is.

Answer 3

I think if you asked the same question today it would also be closed. But rather than "not programming related", it would be "belongs on server fault".

If your question had been, I want to trace the files my program touches, i.e. specifcally related to development work, then it would be marginal.

Answer 4

System admin, I agree is not for this forum, like "How to I make qmail do X?", but is "My smtp virus scanner is not fast enough, based on dnotify?" (answer) "Hey, use inotify", so easy to discreminate? The latter may either be shell or linux kernel system call's.

We don't need to discriminate. If someone is writing a smtp virus scanner, that is a programming task, and questions about how to do it are programming questions. Then it doesn't matter if it is written in bash, assembly or C++ or Whitespace.

On the other hand, asking "how do I see which processes are running on Unix?" is not a programming question. Yes, the answer will be to use a command which is basically a wrapper around a system call, and so what? The MS Word "save file" dialog is a wrapper around a write file system call too. That doesn't make it programming-related.

I don't really see the problem.

Is it not the case that UNIX systems related questions are programming questions? If not, where is the boundry between a programming/scripting language and user interface?

The boundary is here: "Is the question made in a programming context?" A end-user asking how to use some Unix command is not a programming question. But a programmer asking how to make his program do something on Unix, is programming-related.

It doesn't matter that the shell command and the system call are basically identical. If it is invoked from a programming context, it is programming-related. Otherwise it is not. We can even make the same distinction on Windows. If I ask "How should I call CreateFile from my Python program", that is clearly programming-related. But "The program I was running crashed, and gave me an error message saying CreateFile failed. What does that mean?" is not programming-related.

One is asked from a programming context, the other simply happens to include the name of a system call.

If you're in doubt, here's Wikipedia's definition of "programming":

Computer programming (often shortened to programming or coding) is the process of writing, testing, debugging/troubleshooting, and maintaining the source code of computer programs

That seems pretty clear to me. Are you reading/writing source code? If not, it's hardly programming. Being the user of a utility that was created through programming is enough.