POSIX C Programming sub-board?

[Nominal Animal]

I don't see a complaints about learning language standard components before other components as being meaningful.

Well, to be direct, I'm referring to having to teach "new" programmers quite a bit of POSIX.1 stuff, just to get their output into any kind of semi-acceptable state.

In other words, I see programmers learning POSIX.1 interfaces on their own, on top of pretty much wonky concepts, and a majority of them getting it wrong. Then, it takes quite a bit of remedial discussions and advice to get their concepts to a more productive state.

I did not write it in the initial post that way, because of how Windows-only programmers would feel about that. (They're perfectly productive in a Windows environment; why wouldn't their output be considered acceptable in other environments, too? In POSIX environments, their code is like making polygonal wheels out of cardboard, while perfectly good, wide selection of tires are available.)

Fact is, almost none of the tutorials on the web -- including here at cprogramming.com -- teach efficient usage of C99, even less POSIX.1. Even the Linux programming tutorials, books, and manuals often neglect to mention the portability of used features, especially any obstacles to portability.

It is a waste of resources, to put bluntly.

I don't think there's any intrinsic value to learn POSIX from the get go, as opposed to plain C.

I disagree. For example, you'll never be able to write a tree traversal that is robust even when entries are being renamed or deleted using plain C interfaces. nftw() et al. are supposed to handle those correctly. Whether they do, is a matter of architecture and platform-specific C library implementation, but in my experience, they're pretty robust already.

You just have two learn the two anyways.

Well, what I've seen happening, that does not happen until they encounter someone like me, who won't accept their crappy, leaky output.

Producing the correct outputs when given test inputs is not enough; software should not crash or damage unrelated results or data just because some of the inputs were in the wrong format. Detecting and reporting errors is as important as producing correct outputs; otherwise, how do you know when to trust the output? Recheck by hand?

One of the typical examples of that attitude is never checking the return value from scanf() functions. That practice should be curb-stomped, hard, before it becomes a habit to anyone.

tl;dr

I do have similar issues with Fortran. Specifically, not utilizing Fortran 95 features, module interfaces, forall loops, and so on. Not because I like F95 more, but because it allows the compiler to generate better code (especially better vectorized code) without changing the results produced by the code.

I'm not complaining about that here (that much), because there is no Fortran board here.

When before we had a programming culture centered on principles of code correctness and quality, today bugs are ok and expected.

You thought you were veering off with that discussion, but the fact is, that is very close to why I'd like a sub-board to discuss problem-solving using C99 and POSIX.1 interfaces.

You see, it's not that bugs are OK and expected; it is more that people are only considering a very limited inputs and processing conditions, and everything else is somebody elses problem.

(If it passes what the boss asked, it's good, even if it does not actually work for the business case it was intended to. And since it does what the boss asked, the boss will have a hard time pinning it on the programmer, because the ultimate problem is being a boss who cannot choose good programmers or describe tasks to sufficient detail. So, the problem and blame gets shuffled to others. Been there. Because people like me won't stay quiet about such problems, we're easy targets for blame-shifting too.)

For the new sub-board, I don't think it would be a horrible idea, just a little redundant.

What about the clash with Windows C programmers? Don't you think it might cause unnecessary friction among those who cannot use all of C99 or POSIX, especially if they see a simple answer to their question -- but one that they cannot use?

I personally do get a bit miffed, when reading a question, getting interested, starting to think of ways to help .. then suddenly see the fflush(stdin); or similar, and realize the asker requires help with Windows-specific behaviour, with which I cannot help.

I think at one point - largely before the invention and advent of GUI - it would have been true that everyone should learn to program.

I believe people should be taught to use multiple tools to solve problems. Not always relying on Excel or some other spreadsheet for statistics; you might get the same thing done with a single line awk script if the data was already in a CSV file. Then, you could automate it with a few lines of Python and Qt.

Reeling this back to the original topic, I don't think every C programmer should be taught the traditional ANSI C approaches anymore. I believe the POSIX.1 interfaces (and especially the thread-safe ones, like strtok_r() instead of strtok()) should be the priority, with the ANSI C stuff (like fgets(), gets(), and so on) as just a footnote.

Also I hear more and more of previously isolated systems being interfaced with IP and other protocols to do remote management and other things with regular computers acting as clients.

Surprisingly, also a part of the reason for this thread.

Traditional ANSI C/C89 C library is a loaded footgun. It is chock full of hidden dangers, from buffer overruns to non-reentrancy. Teaching it is like teaching a language that has no words to describe whole classes of dangers. Out of sight, out of mind.

With C99 and POSIX.1 libraries, we've figuratively burned our fingers so many times with the old interfaces that we agreed on new ones (that were developed as GNU or BSD extensions, and found to work better). While these are far from perfect, they are an improvement: at least now we have uncovered some of the dangers (especially reentrancy issues), and found ways of protecting against some of them (compare fgets() and getline() behaviour). Now, the various problems are clearly shown in the interface, in the function prototypes. Not out of sight, hopefully not out of mind either.

For example, I suspect that many of those who've managed to read this far, have wondered what would reentrancy have to do with microcontrollers. No, I don't think we'll switch to multi-core microcontrollers, that's not it. Microcontrollers do, however, utilize a lot of interrupt functionality; this is very similar to POSIX.1 signals. Atomicity, hidden state in library functions, and so on, need pretty much exactly the same kind of solutions for the two.

Obviously, most microcontrollers use nonstandard libraries, and they avoid most of those issues by simply defining interfaces where most of those problems are avoided. Still, I think that being familiar with the C99 and POSIX.1 features that avoid similar issues, would make it likelier that developers for microcontrollers and embedded systems would utilize the known solutions, instead of writing buggy code, and hoping nobody will notice.

Most gadgets nowadays are frustratingly unreliable. Sure, some of it is planned obsolescence and cheap materials, but most of it is poor software design. Your 3D printers' end stops are used for homing, but they do not actually stop the device when it is working. Your WiFi-enabled gadget has a "hidden" Telnet port with a fixed username and password the manufacturer uses to update the firmware (except they never have, as the firmware development team was fired when the first version got to market).

"We'll fix the bugs later" has become the standard way of software engineering, and I hate that.

I think my ulterior motive in asking for a POSIX.1 sub-board was an irrational hope that there one could brusquely curb-stomp buggy and bug-prone suggestions, instead of hand-holding and politically correct encouragement, without being pressured to accept all suggestions as equally valuable and precious.

Nah, not going to happen. Might be detrimental to ad revenue, considering that politically incorrect speech is a worse offense nowadays than risking other peoples lives for personal gain.

Hm. I think I'll have to ask my Mistress if she'll allow me to set up my own discussion board, please. Now, where did I put my ball gag?

[MutantJohn]

Fact is, almost none of the tutorials on the web -- including here at cprogramming.com -- teach efficient usage of C99, even less POSIX.1. Even the Linux programming tutorials, books, and manuals often neglect to mention the portability of used features, especially any obstacles to portability.

Don't forget that C11 is now also a thing too!

[Alpo]

Programming is well defined. There is nothing exclusionary about saying that dragging pretty little boxes around a GUI to generate an XML file is not programming. Similarly, creating a XML file in a raw editor isn't programming either.

Exclusion - the process or state of excluding or being excluded.

It's the definition of exclusion that saying something is not a part is exclusion. It's independent of the connotations of the word, which is what I think you mean (You mean HTML writers shouldn't feel excluded?).

Programming also has multiple definitions that overlap in the context of describing what a computer will do. For instance scheduling tasks is technically computer programming, in that you are setting a series of events in motion for a computer (scheduling something being the alternative definition), but also not programming in that you are not writing a program.

But again I need to say that I've not seen the place where all people are encouraged to learn programming (Was it in an article or video somewhere?). I'm just going on the assumption that it could possibly have the meaning of learning to control what a computer does (as I said), an in that context it makes sense that people in modern careers should learn it.

"Everyone can program" invariably results in a lack of formal training in computer sciences. And from that, a lack of proper understanding of the terms and their meanings. I don't mean to say this in a pejorative sense. It is just the realization of a fact; that without a proper understanding of the underlying concepts, people tend to relativize and downplay their meaning, while scoffing at anyone trying to keep things in their places.

Are you saying that if everyone is considered a programmer, then that would mean that the term programmer would loose it's connotation as one trained in computer science?

A programmer is just a person who writes programs, using your preferred definition, it has no bearing on their understanding of any underlying concepts associated with computer science.

[whiteflags]

I think my ulterior motive in asking for a POSIX.1 sub-board was an irrational hope that there one could brusquely curb-stomp buggy and bug-prone suggestions, instead of hand-holding and politically correct encouragement, without being pressured to accept all suggestions as equally valuable and precious.

Nah, not going to happen. Might be detrimental to ad revenue, considering that politically incorrect speech is a worse offense nowadays than risking other peoples lives for personal gain.

Hm. I think I'll have to ask my Mistress if she'll allow me to set up my own discussion board, please. Now, where did I put my ball gag?

I wouldn't give up until you PM webmaster and tell him to peek at the thread or just ask him to make what you want.

I don't really have a problem with a new board, but I've only gotten more lackadaisical with age anyway.

But again I need to say that I've not seen the place where all people are encouraged to learn programming (Was it in an article or video somewhere?)

You would have had to follow the meme for a while to know where it's coming from. The reason I think it's marketing is because I see it a lot on Twitter et al. but if you don't use social media, then like most things on the internet, it's invisible.

[laserlight]

Programming is well defined. There is nothing exclusionary about saying that dragging pretty little boxes around a GUI to generate an XML file is not programming. Similarly, creating a XML file in a raw editor isn't programming either. For one, XML files are descriptive, not instructional. They are nouns, not verbs. "Mary Johnes, Age 12, Dark Skin, Female" is not an instruction. (And neither are XML schemas, btw).

But more than that, creating a well defined XML file is part of the process of Software Development, not programming. Programming is a subset task of Software Development and is the process that directly originates executable code. This is also why HTML, CSS or SQL are not considered programming languages.

I do not think that "programming is well defined" insofar as what exactly is a "programming language" remains debatable to this day. You have implied one possible definition by saying that programming "is the process that directly originates executable code", but depending on how one defines "executable code" that could well rule out say, scripts in scripting languages that are typically interpreted at run time, or rule out programs in languages that are typically compiled to bytecode, or even include SQL (which may be compiled to bytecode and executed). Ruling out XML because "XML files are descriptive, not instructional" is also sufficiently broad as to possibly rule out say, strictly functional programming languages, Prolog, and XSLT (which under another definition might be regarded as a programming language since it is Turing complete).

Reeling this back to the original topic, I don't think every C programmer should be taught the traditional ANSI C approaches anymore. I believe the POSIX.1 interfaces (and especially the thread-safe ones, like strtok_r() instead of strtok()) should be the priority, with the ANSI C stuff (like fgets(), gets(), and so on) as just a footnote.

I think that some these functions should be standardised instead. They are no more platform-specific than what is already in the standard library. After all, strtok_s is an optional part of the standard library, and it has behaviour similiar to strtok_r in some respects.

That said, I consider it a mistake to discard fgets in a pedagogical revision: POSIX getline requires dynamic memory allocation where fgets does not (with the caveat of a maximum line length as otherwise one might resort to dynamic memory allocation anyway), and while this is generally a strength, it is a weakness in a language that has neither RAII nor garbage collection by default.

[phantomotap]

O_o

So ignoring the argument about learning POSIX over C99 standard interfaces, one could sum up your reasons here as:

$): too much educational material is strangely unsophisticated if not simply wrong
$): people who are ostensibly adults can't take having their work criticized
$): lazy programmers are lazy
$): willfully incompetent programmers exist

Yeah. The majority of your complains have nothing to do with the POSIX standard.

You could teach POSIX from scratch if you want, but you aren't going to magic programmers into writing robust code.

A new forum will not buy you anything if you are just going to bark at visitors to rewrite their code using robust techniques. As you imply, the visitor will leave to find a babysitter.

You will never get the average programmer to rigorously check for errors. Our own MutantJohn, for example, thinks always checking return values is a waste of time.

When we somehow crossed into "Everyone should learn to program.", we gained too many people who don't want to learn how to write robust code because the problem solving underlying programming is actually difficult.

*shrug*

I'm with you on renaming the "LINUX Programming" board, and I'll happily throw in with you if you want to ask the owner (webmaster?), but I think you'd be happier if you asked Yarin... I mean Mistress... to help you learn to not care about "being pressured to accept all suggestions as equally valuable and precious". Seriously, say what you need to say to protect people from nonsense regardless of who you upset. If the forum or whatever tosses you, it is their loss.

Soma

[laserlight]

When we somehow crossed into "Everyone should learn to program.", we gained too many people who don't want to learn how to write robust code because the problem solving underlying programming is actually difficult.

I am in favour of everyone learning to program, but in the sense that say, everyone should learn mathematics. After all, the work of a mathematics student prior to university, or even at undergraduate level in university, is very different from that of a professional mathematician, yet there is some value to be gained in teaching students mathematical tools that they might never use, mainly in thinking and general knowledge. Likewise, I think that having students learn enough to come up with simple algorithms and implement them would be useful to develop their thinking and broaden their general knowledge, but one cannot reasonably expect such exercises to be anything like the job of a professional software developer.

The difference perhaps is that wanna-be mathematicians, unless they happen to be sufficiently brilliant such that they are truly expert despite a lack of further mathematical training, are likely to be totally sidelined because their work simply will not pass review to get published, whereas wanna-be programmers could feasibly get their code out where people would actually run it in production.

[Mario F.]

I disagree. For example, you'll never be able to write a tree traversal that is robust even when entries are being renamed or deleted using plain C interfaces.

Your advocacy makes no sense. I did not close my world to nftw() because I decided to learn standard C first. By learning either one of them I will be able to learn the other quickly and for the good reasons. The intrinsic advantages of POSIX C are irrelevant when deciding what to learn first, if Standard C or POSIX C.

Programming also has multiple definitions that overlap in the context of describing what a computer will do. For instance scheduling tasks is technically computer programming

I see...

Are you saying that if everyone is considered a programmer, then that would mean that the term programmer would loose it's connotation as one trained in computer science?

"Are you saying that...", I wish I had a penny for every time someone says this and completely fails to understand what was being said.

A programmer is just a person who writes programs, using your preferred definition, it has no bearing on their understanding of any underlying concepts associated with computer science.

A physicist is also a person that does physics and it has no bearing on their understanding of any underlying concepts associated with physics.

I do not think that "programming is well defined" insofar as what exactly is a "programming language" remains debatable to this day. You have implied one possible definition by saying that programming "is the process that directly originates executable code", but depending on how one defines "executable code" that could well rule out say, scripts in scripting languages that are typically interpreted at run time, or rule out programs in languages that are typically compiled to bytecode, or even include SQL (which may be compiled to bytecode and executed). Ruling out XML because "XML files are descriptive, not instructional" is also sufficiently broad as to possibly rule out say, strictly functional programming languages, Prolog, and XSLT (which under another definition might be regarded as a programming language since it is Turing complete).

Admittedly there's some latitude in the definition. But I think it doesn't allow for some of the things that were being discussed here, like XML files and now task scheduling.

[Alpo]

"Are you saying that...", I wish I had a penny for every time someone says this and completely fails to understand what was being said.

Umm yeah, why else would they ask?

I see...

In case this is sarcasm, which I think it is. I won't ask though, you have enough pennies.

[MutantJohn]

You will never get the average programmer to rigorously check for errors. Our own MutantJohn, for example, thinks always checking return values is a waste of time.

Lol way to throw me under the bus XD

jk

Anyway, it really depends on how much you trust the code you've written/how confident you are that you've written it correctly. This almost sounds like something I've said long ago. You should know by now phantom I repeatedly say stupid things because I'm thinking back and I check code pretty rigorously now but mostly through visual inspection. Like, allocating a Cartesian point set for example. It's easier to just have it do a visual dump of the data. But I've started wrapping those in :

#define print
#ifdef print

....

#undef print
#endif

so it's easy to turn debugging on and off for critical sections.

I think what I might've meant oh so long ago is, if you have this :

struct point
{
    double c[ 3 ];

    point( double x, double y, double z ) { c[ 0 ] = x; c[ 1 ] = y; c[ 2 ] = z; }
};

, do you really need to check for errors? I mean, you could but at the same time, this is so small that I'd be surprised if it didn't work.

[Mario F.]

[google link] which I think it is. I won't ask though, you have enough pennies.

Frankly, I'm stopping here. You are really just proving my point. And you don't even seem to realize that, which just doubles down.

[Alpo]

How does a google link to the definition of programming prove your point that programming has only one definition? The link clearly shows 2 terms, and the original meme spread on Twitter was that "Everyone should learn programming". My entire point was that the definition is ambiguous and those people could mean anything from learning about memory management to changing the drivers that load on start.

[Mario F.]

How does a google link to the definition of programming prove your point that programming has only one definition? The link clearly shows 2 terms, and the original meme spread on Twitter was that "Everyone should learn programming". My entire point was that the definition is ambiguous and those people could mean anything from learning about memory management to changing the drivers that load on start.

Twitter? What are you talking about? I don't read tweets. I don't even have an account.

Anyways, the problem really is what one person perceives as programming from generic definitions and what someone else perceives as programming from a more formal definition.

If you which to follow the path of generic definitions, that is your prerogative. According to it, I'll be finishing this piece of programming I'm doing right now when I click on the "post reply" button. The silliness of it all is beyond my desire to even reflect upon. Stupid is stupid.

Alternative, you may which to pay attention to what I'm telling you and maybe learn something. That there are more formal definitions. Certainly these definitions aren't laws. You can't accurately define such a complex process as that of programming. But you can and you should establish certain boundaries. Elastic as they may be. And these boundaries do exist. Within the field of Computer Science, which I'm not sure you know is an actual science and is actually studied and is actually being developed, programming is generally agreed to have nothing to do with task schedulers, XML files, turning your computer on or off, or whatever the hell you wish to come up with next. If you wish to insist "but other definitions say XYZ" then you are just proving my point; that relativism is the province of uninformed minds and pity anyone who tries to defeat it, for they will be called pedantic.

[Alpo]

Alternative, you may which to pay attention to what I'm telling you and maybe learn something. That there are more formal definitions. Certainly these definitions aren't laws. You can't accurately define such a complex process as that of programming. But you can and you should establish certain boundaries. Elastic as they may be. And these boundaries do exist. Within the field of Computer Science, which I'm not sure you know is an actual science and is actually studied and is actually being developed, programming is generally agreed to have nothing to do with task schedulers, XML files, turning your computer on or off, or whatever the hell you wish to come up with next. If you wish to insist "but other definitions say XYZ" then you are just proving my point; that relativism is the province of uninformed minds and pity anyone who tries to defeat it, for they will be called pedantic.

Ok, I understand you. However my point was to interpret the intentions of the ones who started the meme, and I'm still guessing all that is meant is to be able to use a computer better. Although advocating programming as being good for learning overall would also make sense.

Let me ask you this, is hardware implementing logic circuits programming in your definition?

[Mario F.]

It's not a meme, Alpo (I think I understand now why you were talking about twitter). You may haven't noticed it. I dunno, maybe you visit few programming communities. But for some years now (starting maybe 10 years ago or something), programming culture has been changing to include the increasing notion that anyone can become a programmer and that programming is easy. That culture is what is being discussed here.

Let me ask you this, is hardware implementing logic circuits programming in your definition?

No, it isn't.

Look, this whole thing is only as difficult as you are making it to be. No field benefits from over-simplifications or generalizations. Accuracy and precision are where anyone stands to gain. Programming as a process is already complex enough and hard enough to accurately define. It has nothing, I mean nothing, to gain from over simplification. The tendency should be to constrict and delineate a definition, not to expand it until it becomes useless.

Now, I don't know how it is down there on MIT or any other reputable university over there. But I can guess, from how it is from where I come from, that you are taught what programming is and how to program in either a CS or SE course. And I'm sure it doesn't involve writing XML files, scheduling computer tasks, or soldering circuit boards. That should help you at least to narrow it down. The more debatable issues of SQL or HTML as programming languages, I'll leave for you to decide. You won't be wrong either way, although you will find varying opinions on the matter.