I know nothing of programming, but I would love to learn.
Here is what my naive approach would be, which I assume would take about 6-7 months of study.
I would first learn the fundamentals on a bare-bones *nix system like Debian or possibly FreeBSD, using an editor like Vim, and the GCC.
[Fundamentals]
Basic C programming
Basic C data structures
Advanced Unix Programming
Assembly
Computer Architecture and Design
DNS & BIND
TCP & IP
Unix Network Programming
HTML/XML
Apache
MySQL
1 scripting language: PHP, Perl, Ruby, Python, Lua, etc...
Visual Studio (C++)
ASP.net
Ajax
Along the way I would learn about GNU make, CVS, Digital Logic, the Windows Registry, and fully understand a text on Discrete Mathematics.
Some projects along the way might include:
an imageboard
an instant messenger / irc client
a game
a device driver
Professional programmers please feel free to laugh, yet modify and correct.
That might take a bit longer than 6 months.
Also, jack of all trades, master of none.
>>2
all of the above fall under [Fundamentals]
But exactly what should one specialize in nowadays?
What should one master (to make money)?
>>4
I agree. I have heard that nowadays C will not really pay off. For beginners I recommend Python and Perl.
>>4
I agree. It seems C will not really pay off. For beginners I recommend Python and Perl.
Why is everyone here such a fucking pussy?
such a motherfucking gay nigger faggot?
i seriously wish i could stab every posters neck in this thread except moi, with an icepick.
you do know the japanese might be watching us right?
jesus fuck...
Can we please not go the direction of 4chan?
The reason for learning something other than C for a first language is quite simple: novices like fast feedback, and they need to see that their effort is paying of. C provides neither of these. It doesn't have a REPL, it requires compilation, and a great deal of code is needed to do simple things.
Actually, veteran programmers also need fast feedback. The quicker you can make the edit-compile-test cycle, the sooner you get a working product. The customer is happier, and so is the developer.
Now, working at a low level can be fun too, but I don't think it'll do for a novice. I started with BASIC, which let me draw a line or circle on the screen with a program that consisted of two simple statements. Last I looked, base SDL doesn't even come with functions that draw geometric primitives.
Allegro does, but it gets little love from OSS world. I digress.
>>1
Ok, learning Python would be a good first start (like others said). All Python distributions come with a GUI kit now, so it's even better as a starter language. And install pygame for any sort of 2d graphics onto the screen. When you've decided you're good enough, learn C++ and SDL (not that hard really, but installing SDL for a compiler is a P.I.T.A.)
>>9
GTFO the internet. How old are you, 10? Asshat...
There's absolutely nothing wrong with learning C as the first language. As languages go, it's rather small; as in, very few commands and standard types and a standard library whose documentation condenses down to one tenth of C++'s (or Java's, or Perl's, or whatever) equivalent. Small things are easier to learn than large things, since after the basics one does not have to go to the manual fifteen times in as many minutes.
Learning C gets you rid of your fear of pointers. It also makes every grotty detail apart from the actual instructions presented to the processor explicit. It doesn't force its user into wearing thick gloves for fear of segmentation faults, and it doesn't enforce any particular level of abstraction. There's nothing you can't do with C, the preprocessor and a bit of elbow grease. For these reasons, I recommend C as the first programming language for everyone.
Once C has been learned, programmers can feel free to wrap themselves in the warm, fluffy blankets of abstraction and "you don't need to know that". Even better, such programmers will understand what the abstraction means, and will be able (perhaps with a bit of effort) to see through the abstraction and into the concrete where necessary.
Contrast this with the alternative -- pitiful people who've been taught to fear the real world, relying on "someone else" to cushion and separate them from the machine via frameworks and design pattern liturgy. Fretting over how pointers are difficult and scary like some modern-day Barbie.
When i was younger i could not understand why people recommended python/etc instead of C to a newbie.
Being an uber guru that started with C, knowing C and many assemblers i believed that everyone should start with C.
Now, after so many years i finally understand.
And when you understand you'll shit bricks.
>>13
Yeah and tell a newbie that char buffer[] is not the same with char *buffer and then explain to him pointer arithmetic and the use of void pointers, typecasting, expressions and the tern. operator, about addressof/sizeof and structs being arrays in memory
Then tell him that the standard datatypes char,int,float,double can have any value and size depending from millions of things, explain him about c89 c99 POSIX preprocessor libraries stack heap dynamic memory allocation buffer overflows floating point high/low bit order signedness bitwise operators etc etc
Then explain him how to use gcc optimization warnings standards architecture cross compilation -O3 considered harmful blablabla
A newbie just by reading my post would get a headache; imagine actually learning it.
>>15
Say wut?
char buffer[60] behaves very much like char *buffer, except in the latter case no storage is allocated and the pointer goes nowhere until assigned. The finer distinctions can be ignored until the second course on C programming; just like you and I did way back when.
Pointer arithmetic is perhaps worth 30 minutes of explaining and a few slides. Void pointers are a simple enough topic, to be explained once malloc() and free() have been. Typecasting, expressions and the ternary operator are things that any Java course has to deal with, and it apparently isn't giving them any insurmountable problems. The in-memory format of structs is again something for the advanced half of a two- or three-course whole.
The sizes of standard datatypes can be explained as they are in the Typical Modern Implementation on a Typical Modern ABI. Students who're particularly interested can go crawl through the standard, which is pointed to in a footnote of the lecture material.
The preprocessor can be explained by the course book; there's nothing particularly advanced or hairy there. POSIX is out of scope for a set of courses on C. Libraries are a particular case of modular programming. Memory allocation is not especially difficult. Buffer overflows etc. can be explained in terms of undefined behaviour, i.e. nasal demons; their prevention is better explained in the context of a course on security-conscious programming (the principles of which apply just the same to Java as they do to C).
Numeric programming is a broad enough topic to be in a course of its own, and typically is. Signedness of numbers is CS 101, as are bitwise operations. Use of the compiler can be explained with a 5-page appendix of the lecture material, with a link to the manual pages and a hearty note of "you don't really need more than the first page until we get to modular programming".
Don't underestimate newbies. You were one, once, and look at yourself now.
> char buffer[60] behaves very much like char *buffer
here are some examples
1:
int f(char **p) { ...
int main() {
char *p;
char buffer[10];
f(&p); /* correct */
f(&buffer); /* compiler complains, why? newbie is confused */2:
char buffer[] = "BBC";
buffer[0] -= 1; /* "ABC" */
char *p = "BBC";
*p -= 1; /* segfault. newbie is confused */*note: sure, you can fix this with this c99 feat
char *p = (char[]){ 'B', 'B', 'C', 0}The newbie will be nonetheless confused
3:
char *p = "something";
/* ... */
p[-1] = 0; /* allowed */char buffer[] = "something";
/* ... */
buffer[-1] /* undefined behavior */Anyway, you make things sound easy, but you are correct, i do underestimate newbies.
That's what experience taught me... people don't want to learn, they want quick solutions.
>>17
1: Ah yes. It obeys much the same syntax as a pointer, yet isn't one. The wonders of modern C, but hardly worse than the old standby, *(p + i), for pointer subscripts. Still, it's easy enough to look at the variable's declaration and proceed from there. A pointer-to-pointer sort of implies that it is a pointer to a pointer variable or equivalent anyway. Most people, I'd think, would rather live with a a rarely hit special rather than the classic pointer subscript syntax (which I personally find rather nigh to obfuscation).
2: My personal pet peeve with C, that string literals are not "const char *" by default. To think that this was for historical reasons that would've been overcome had the change been made in C89... Still, hands off string literals seems like a simple enough policy to follow. Initialization of an array from a literal shouldn't give even newbies pause after the first time.
3: I don't think your case of accessing a string literal before its first byte is permitted, though not having read the standard recently I could just as well be wrong. It'd seem that the minus first would go into some ill-defined place in the process' text section, which far as I'm concerned pretty darn well counts as undefined behaviour especially when that position is being modified. Unless the standard specifies that doing that must crash the program, which I rather doubt.
I may be in optimism mode today, however, my experience is that things are easier when one stops making them hard. (Your example with the integral types' ill-specifiedness in the standard for instance.) Like in any line of creative or semi-creative work, the artist is his own worst enemy. Yet any journey can be split up into kilometers, then meters, steps and so forth.
I do wish people wised the fuck up with regard to the quick fix thing. Oh well, experience beats any lecturer in the field of teaching... sadly some people only learn to bang their head on the wall harder. It would certainly be nice if the school system(s) made these lessons available to students as early as possible instead of shielding them from well-deserved disappointment.
>>18
I think i was not very clear with the 3rd example
It is illegal to access the -1th element of an array, however it is not illegal to substract 1 from a pointer and dereference it.
> I may be in optimism mode today, however, my experience is that things are easier when one stops making them hard. (Your example with the integral types' ill-specifiedness in the standard for instance.) Like in any line of creative or semi-creative work, the artist is his own worst enemy. Yet any journey can be split up into kilometers, then meters, steps and so forth.
I agree.
> 2: My personal pet peeve with C, that string literals are not "const char *" by default.
IIRC, this is the case with GCC.
>>20
They are const in the sense that there'll be segfaults if one tries to write to them. But their type is not "const char *", judging from GCC not screaming if you do
char *str = "literal string";like it would if you did
const char *lit = "literal string";
char *str = lit;1dSyuY9L here
The standard(s) state very clear that it is UB if you try to write to a string literal.
However some extensions allow it.
It's not the 'case' with GCC; it's the 'case' with every compiler that allows it.