Toolchain

Just a note, rjh, for if/when you fill out the Toolchain page, that we already have two (not very well maintained) related pages C resources:Compilers and C resources:IDEs which could be integrated or somehow used for the purpose. I'd be happy to fill out that page if you want to delegate it, otherwise will let you get on with your thing. --Laird (talk) 13:39, 21 April 2015 (UTC)

A major rewrite of the first twelve chapters is under way. I'm going to upload them as a block, though. The first chapter will still refer to a tool chain page, though. This should probably be a tutorial in its own right - what tools you need, why, how you use them, etc, with perhaps dedicated pages for particular compilers, shells, IDEs, debuggers, and so on. The Toolchain page would be not much more than a portal into those pages. I don't expect that I shall be writing any of that stuff any time soon, though! It's standalone, it doesn't affect the tutorial in any way (other than through its current absence), so there's no reason why someone with far too much time on their hands shouldn't take it on. In fact, it would be better for each page to be written by someone who actually knows that particular program (be it gcc, Borland C++, the Win32 command shell, gvim, cflow, or whatever it is) really really well. If you were looking for an easy and useful project, you might want to put a skeleton format together that people could plug into. (By the way, are you and I the only ones contributing to this wiki?) --Rjh (talk) 14:53, 21 April 2015 (UTC)

Ah, cool, I'll cancel my in-progress proofreading of the first twelve chapters then. Perhaps I'll put together a page for the particular toolchain that I use, and then abstract a skeleton out of it. Yes, other than the odd one-time or at least short-lived contributor, it's just you and me. Until you came along, I was wondering whether the wiki should even continue, as incomplete and abandoned as it has been. It does get a fair few hits though. --Laird (talk) 15:06, 21 April 2015 (UTC)

P.S. The tutorial reads really well to me right now, I'm not sure how much rewriting you need to do. --Laird (talk) 15:40, 21 April 2015 (UTC)

Most of the actual text will remain. It's the organisation that's changing, because I think this will lead to a more structured learning process. So your proof-reading isn't wasted! But the proof might move around a bit in the next week or two. --Rjh (talk) 20:28, 21 April 2015 (UTC)

No worries, sounds like you know what you're doing. By the way, the syntax highlighting colour for C string literals has changed from red to a hopefully better fit, so please speak up if you don't think it's quite right - I'm not all that sure about it myself, but it's definitely an improvement, and a long-overdue one. --Laird (talk) 21:24, 21 April 2015 (UTC)

Historical discussion

Who chose red for a string literal? And have they been caught yet? :-) [unsigned comment by rjh on 16:09, 14 March 2006 GMT]

The one who made the C code highlight php module. Please, in discussion provide a signature for the others to know who is talking. Also, do not add much content yet, since there are some tasks pending, such as 1) how will the tutorial progress 2) templates for DID YOU KNOW THAT, HINT, WARNING etc.

Since this is going to be a simple tutorial, I believe we can spare phrases like "This may not sound terribly difficult - and indeed it isn't!". Since this is not a book, it must be with small paragraphs and clear explanations. The discussion will be moved to Category:C_tutorial [now Talk:C tutorial --Netocrat 04:50, 27 June 2006 (BST)] discussion area, this is only the discussion for Chapter 0. --dop 17:04, 14 March 2006 (GMT)

rjh: according to comments in the GeSHi code, the perpetrator is one Nigel McNie; judging by the news and demo pages, said perp is unrepentant and on the loose - lock up your kids. dop: I'm fine with brevity as a constraint for this tutorial; and if you'd prefer to avoid too much conversational language, that's also OK with me. I don't think that technical writing needs to be totally bland though, even when brevity is required; perhaps you found some of rjh's language inappropriate for the aims of the tutorial, but at least some character in technical writing is nice to have. Why don't you explain in the talk page for the category just what style you envisage the tutorial having, and what role character will have? --Netocrat 22:52, 14 March 2006 (GMT)

rjh: btw, I share your opinion that the colour scheme could be improved, even if my previous comment came across as glib - if you have a better scheme in mind, I'm sure Flash will patch it into the extension, the source of which is detailed at Planning:Wiki_customisation#Syntax_Highlighting. --Netocrat 01:32, 15 March 2006 (GMT)

I find it extremely difficult to read tutorials with very long paragraphs - so do other people I have questionned, outside clc and clc-wiki. Since it is tutorial that its primary purpose is to be a tutorial, and not a book - in which a lot of comments can be included - I strongly believe that clarity and brevity, without too much technicalities is the most appropriate. It is nice to have a good writing style, that has also some "relaxing" comments, however I believe that comments like "Wasn't that simple?" and others can be omitted. I refer everybody to http://java.sun.com/docs/books/tutorial/getStarted/cupojava/win32.html , Sun's Java Tutorial which, IMO, is really helpful and is perfect for anyone to start with Java. What do you think? --dop 00:43, 15 March 2006 (GMT)

I wouldn't want to attempt to write a better comprehensive tutorial than K&R2 - it fits the penultimate description very well. This wiki's tutorial needn't be more than a bootstrapping of a new C programmer so that the reference material on the rest of the site becomes comprehensible. So I think that as I wrote above, there's scope for some character in the tutorial, but that too much is distracting. We'll probably all have different ideas of how much is sensible, which we can work out as we go. I also agree that short paragraphs are best in technical writing. --Netocrat 01:32, 15 March 2006 (GMT)

I have already noticed at least one change to text I have written which was correct, and which - as a result of the change - is now incorrect. If you want a broken tutorial, why not just pick up a copy of Schildt? Sheesh. This is *exactly* the same problem that wikipedia.org has! --Rjh 02:00, 15 March 2006 (GMT)

First off, please keep meta-discussion to the talk page (FYI, in wiki etiquette terms what you did was something vaguely akin to an OT post in clc). I've brought it in from the article:

The first line, #include <stdio.h>, is a preprocessor directive; this instructs the compiler to incorporate a standard header into the program, making available to it a number of standard functions that are well defined and that exist in every ISO C conformant compiler. In this case, it makes the puts() function available to the program.

Whoever wrote the above paragraph doesn't understand what headers do, doesn't understand what compilers are for, doesn't understand what libraries are for, and doesn't understand when to use the word "conforming". You need to tighten up on your editorial policy. [unsigned comment by rjh on the article page 13:31, 15 March 2006 (GMT)]

I was the last to edit that paragraph, mostly to try to fix up the grammar of dop's earlier edit of your writing; being preoccupied with form I missed the subtle lacks in substance. I can't see what beef you have with the use of "conformant" though unless it's related to the compiler/library/implementation distinction. In any case, if you suspect that other editors don't grasp the concepts, please explain your corrections on the talk page.

I've edited that paragraph to reflect more closely your original wording; please re-edit with explanation if it fails to meet your standards.

I'll note in passing that you've ignored the discussion dop initiated re style. --Netocrat 04:06, 15 March 2006 (GMT)

Which is more important? Style or substance? If my style is a bit wordy for some people, I'm okay with them editing it down - that's what a wiki could be very good for - but surely it's paramount not to introduce errors by so doing? --Rjh 09:58, 15 March 2006 (GMT)

Agreed. --Netocrat 19:44, 15 March 2006 (GMT)

I'm also not sure why you write "you" rather than "we". You have an account on this wiki, in the sysop group no less, a group membership you've been given opportunity to refuse but have chosen to accept. That gives you as much responsibility for editorial policy as anyone else: a wiki is a collaborative effort (granted that others have been more active to date). If you'd like to suggest a workable policy, I for one am keen to hear it. As you know I'm working on software means to assist editorial integrity; it's a slower process than I'd like it to be. scs has a neat idea minus implementation that could be incorporated at some point given implementation impetus. Until then, let's work with what we've got in a cooperative spirit and in good faith, OK? --Netocrat 04:06, 15 March 2006 (GMT)

I suggest the following policy, then - people don't introduce technical errors into this wiki, period. [rjh 09:58, 15 March 2006 (GMT)]

Implicitly that's already policy, but making it explicit is a good idea. Do you have anything more detailed in mind? --Netocrat 19:44, 15 March 2006 (GMT)

I'll suggest to cease any further development on the tutorial and firstly create a rough struct of the tut in Category:C_tutorial (or at least in the discussion area). Since there was no activity in the C tutorial, I started it and thought I was the only one on it. My bad. Since we are more than one that wish to plan the tut, I believe it is now crucial to make suggestions and then get to work. --dop 09:32, 15 March 2006 (GMT)

The first step would be to decide whether one wants a short, sharp, minimalist tutorial (in which case why bother with "Hello world"?, and indeed, why bother at all, when one can just link to Tom Torfs's?), or something that can actually help people who might be struggling. The disclaimer on the current tutorial ("don't use this tutorial to learn C" or whatever it says) is strange. What else would one use a tutorial for? And the kind of people who like a short, sharp tutorial are the kind that will learn C perfectly adequately from K&R. What the C world badly needs is a tutorial for the rest of us. Just the other day, a guy in clc was surprised when foo = bar; bar->baz = quux; led to a change in the value of foo->baz. Clearly, his mental image of pointers is completely out to lunch. One doesn't re-educate such people (or, better, educate them properly in the first place), by giving a ten-word definition of a pointer and then moving on to the next bit. --Rjh 09:58, 15 March 2006 (GMT)

No, it doesn't say that. It says "It is not a replacement for a good C book, but rather an introduction to the language for novice or more experienced programmers that want to experience the C language. To all that start programming now: This tutorial is NOT the best place to start. <snip> The target group of this tutorial is primarily programmers that wish to start with a new language - in that case C . After all, nothing can substitute a good book, not even the Internet.

If someone wishes to learn programming by using that tutorial, it might be difficult - and I DO believe that tutorials cannot substitute books. We are not trying to create a new KR. However, if someone is familiar with any computer language, he/she should be easily able to start with C with this tutorial. Apart from that, I didn't say to keep it minimal, just to make paragraphs shorter (2-5 lines)

The first chapter is a pilot for the whole tutorial: it is a fast start for anyone who wants to see a C program running and it is more like a test place for the tutorial's design (before starting to write anything, we need something to test how it would look like). --dop 10:22, 15 March 2006 (GMT)

It is currently true that Web tutorials are not a substitute for books. It is not true that they cannot be. The only advantages of book format over Web format are (a) one doesn't need electricity to read a book during the daytime, and (b) one can take a book places where one cannot access the Web. Neither of these advantages is particularly earth-shattering, and the Web has many compensating advantages. The only reason Web tutorials have a bad reputation is that there are so many bad ones around, and precious few good ones. --Rjh 10:54, 15 March 2006 (GMT)

You make some good points, as does dop. On reflection, let's leverage use [leverage?! don't know how I let that one slip in...] the online approach to provide for all levels of understanding - a concise tutorial with link-outs to more detailed explanatory pages. --Netocrat 19:44, 15 March 2006 (GMT)

Also, it's conventional to not snip content in wiki talk pages as for newgroup posts - the talk page conventionally contains the entire history of the conversation. I've reinserted the snipped content. --Netocrat 19:44, 15 March 2006 (GMT)