Is C Okay to Learn?

[Noah0504]

When I was about eleven years old, I purchased C for Dummies, Volume One and Two. I read through them, skipping what I didn't understand, and I came out with basic knowledge -- enough to write a very simple program from memory.

Now I'm nineteen and I really can't say I know how to program. Sure, I code HTML like there's no tomorrow, but that's the easy stuff. I want to be able to actually program. I've attempted to learn Python by reading a few tutorials in my spare time, but I really haven't had the time to dig too deep into the language.

I was cleaning out my closet today, and I came across my old C for Dummies books. I never released the full potential out of the books, and I was wondering if there is anything wrong with still using C in 2007. I know C++ is the improved implementation, and Python is easy, yet powerful, but I have these books just sitting there, waiting for me to read them.

Let me know if it's still worth my time to give it another shot!

[cprofitt]

Nothing wrong with using C.

In fact you can use C and Python together.

I personally started with Apple Basic -- years and years ago. Dabbled with Cobol and Fortran in college. The taught myself VB.Net and C# later selling some applications I created with C#. Now I am teaching myself Python and will move over to C++ or Java (leaning towards Java).

Just use what you have and start.

I would recommend Python Programming: An Introduction to Computer Science by Zelle.

The book will help you learn the basic concepts that will carry over in to any other OO language.

[tc101]

Set aside some time every day. Pick a language and a book and every day read a little and write some code.

I made a living as a programmer for 20 years, then recently retired. I have been teaching myself Python. I think it is a good language to learn, especially since you are here in an ubuntu forum.

The language is not so important though. The important thing is to stick with it, and for most people, the only way you will stick with it is if you are having fun.

So have some fun. Make a point of having some fun.

[AlexThomson_NZ]

Hey I still use C every day, despite being a full-time Java programmer, and I found C is surprising still widely used (especially in the Linux world)

Despite what some on here like to suggest, C is a good starting language, in that there are a only few fundamentals, and it scales up nicely. When you start looking at things like GUI and OpenGL programming, the complexity comes in the implementation of these tools rather than the language itself, but look around and make up your own mind.

// Doesn't want to start a language1 vs. language2 flamewar... :)

[Wybiral]

When I was about eleven years old, I purchased C for Dummies, Volume One and Two. I read through them, skipping what I didn't understand, and I came out with basic knowledge -- enough to write a very simple program from memory.

Now I'm nineteen and I really can't say I know how to program. Sure, I code HTML like there's no tomorrow, but that's the easy stuff. I want to be able to actually program. I've attempted to learn Python by reading a few tutorials in my spare time, but I really haven't had the time to dig too deep into the language.

I was cleaning out my closet today, and I came across my old C for Dummies books. I never released the full potential out of the books, and I was wondering if there is anything wrong with still using C in 2007. I know C++ is the improved implementation, and Python is easy, yet powerful, but I have these books just sitting there, waiting for me to read them.

Let me know if it's still worth my time to give it another shot!

C++ is not an improved version of C... It's just an alternate version or "child" of C and a couple of other languages.

C is good. Especially if you're the kind of person who's interested in the underbelly of programming (if you're interested in learning how things work at the low level).

C might not be so good if you plan to go on to object oriented, framework based programming (typically found in todays software industry).

The way I see it, there are two kinds of programming newbies:

A. Those who know little about data structure or computation and want to dive in and learn to program right away.

B. Those who have a decent knowledge of the processes involved with computing and want to invest the time into learning the details about logic, data structures, and the memory management involved.

Either way works. But if you want to hack out a program right now and ignore the details for the time being, I suggest something other then C (perhaps Python).

But if you want to see the low level side before learning about abstraction and OOP, then C may very well be your best option.

[pmasiar]

C is OK and useful language. It is good that you know HTML, and you know that computers are 100% dumb and cannot see a simple typo which human can fix without problem - computer cannot. So you know that, and are ready to learn more.

What is most important when learning language: to have fun while learning, so you can stick with learning. It is painful process to get over the first hump and start coding something, anything.

To have fun, overcome frustrations, to feel some accomplishment, is better to use language which allows you to do simply and easily what you want to do. That's why high-level language (optimized for programmer's productivity, even for price of slightly less effective code) like Python is more productive for beginners: Python allows them to start coding sooner and with less frustration.

Don't thow the C books yet: After you are reasonably comfortable with Python, you can return to your C books, and re-read them again. It is very educational to compare languages - so you can see which part is syntax, and which part is semantics. For non-programmer, "for i in range(10)" and "for (i=0; i<10, i++)" looks very different, but it is just different syntax for writing exactly the same loop (in Python and C). As beginner, especially without a teacher ready to answer all your questions, you are *far* better of with simpler language focused on your productivity, and not productivity of CPU as C is.

Wiki in my sig has many links to free books and training tasks for beginners, to help you start with Python.

I read about experience of some high school teacher who had 2 groups for a year: one started directly in C++ or Java, and other had 3 months of Python as intro to programming (then C++). Second group was able to cover more and accomplished more, because C++ was for then just different syntax.

But you need to set a goal - what do you want to program. Something relevant to you, what you can do and have little bits of fun. Many people are interested in games - Pygame is great library to make games. But I would strongly recommend command-line text games as start: as a beginner, you will have enough confusion with syntax, basic data structures, and debugging, even without handling GUI. If you must have GUI, look at easyGUI - *the* easiest way to make GUI, truly pythonic.

many experienced programmers will tell you: "go for C (or C++ or Java), I use it every day and love it!" It is true, but it is hardly relevant to you: you are not experienced programmer yet :-)

If you really want to do games, there is (sadly Win only) excellent http://en.wikipedia.org/wiki/Game_maker, super-easy visual way to program games using just icons and their properties (you don't write code at all, no text editor is used). You will learn basic programming concepts, and can create rather cool games and share them with friends, but... it is not a standard language which you can use later. But it is good, even easier than python, and *huge* amounts of fun - I know about college using it as intro to programming.

[slavik]

C++ is not an improved version of C... It's just an alternate version or "child" of C and a couple of other languages.

C is good. Especially if you're the kind of person who's interested in the underbelly of programming (if you're interested in learning how things work at the low level).

C might not be so good if you plan to go on to object oriented, framework based programming (typically found in todays software industry).

The way I see it, there are two kinds of programming newbies:

A. Those who know little about data structure or computation and want to dive in and learn to program right away.

B. Those who have a decent knowledge of the processes involved with computing and want to invest the time into learning the details about logic, data structures, and the memory management involved.

Either way works. But if you want to hack out a program right now and ignore the details for the time being, I suggest something other then C (perhaps Python).

But if you want to see the low level side before learning about abstraction and OOP, then C may very well be your best option.
X is object oriented and written in C :)

[vexorian]

C vs. C++ the main selling point for C++ would be std::strings, using things like scanf("%s",a) are some things we should really forget to do...

Of course it can be fixed, but you got to make sure to know what are the risks of null terminated strings. It is also helpful for C++ since a lot of libraries still use those evil, evil null terminated strings...

I think C is a perfect language for an starter if you plan a long career , it will teach you a lot of things that is good to know even if you end up using an ultra dynamic language later, people have survived learning C, it won't kill you.

For example, if you end up using php, you would be able to understand the key difference between aa.="x" and aa = aa . "x" ...

[slavik]

C vs. C++ the main selling point for C++ would be std::strings, using things like scanf("%s",a) are some things we should really forget to do...

Of course it can be fixed, but you got to make sure to know what are the risks of null terminated strings. It is also helpful for C++ since a lot of libraries still use those evil, evil null terminated strings...

I think C is a perfect language for an starter if you plan a long career , it will teach you a lot of things that is good to know even if you end up using an ultra dynamic language later, people have survived learning C, it won't kill you.

For example, if you end up using php, you would be able to understand the key difference between aa.="x" and aa = aa . "x" ...
that's not valid php :P

[vexorian]

yeah I forgot three $ so what? the point remains. This reminds me I haven't messed around with php in ages.

[Wybiral]

X is object oriented and written in C :)

But C isn't an Object orient language. It doesn't support abstraction/methods/encapsulation... etc.

X may use a few OOP concepts, but C is NOT OOP.

[slavik]

But C isn't an Object orient language. It doesn't support abstraction/methods/encapsulation... etc.

X may use a few OOP concepts, but C is NOT OOP.
that is exactly my point ...

methods = functions (are they not?)
abstraction = done by any library (libpurple can be used to connect to a jabber server and such)
encapsulation = is also done in C ...

the thing is that this is very much like distributing a perl module file or a python module file ... you have access to the source anyway. in other words, the programmer is in control. it is up to him to do things according to the documentation of your library, or it will bite him later.

[Wybiral]

that is exactly my point ...

methods = functions (are they not?)
abstraction = done by any library (libpurple can be used to connect to a jabber server and such)
encapsulation = is also done in C ...

the thing is that this is very much like distributing a perl module file or a python module file ... you have access to the source anyway. in other words, the programmer is in control. it is up to him to do things according to the documentation of your library, or it will bite him later.

Method and functions are not the same thing. A method has access to the members of a class. A function requires you to pass a pointer to the "object" (structure) which actually adds to overhead.

As far as abstraction and encapsulation goes... There is no "private" or "protected" keywords in C... It's harder to ensure that a module will be used correctly.

There is also no inheritance in C. If I wanted to make a child "class" I would have to either rewrite it, or I would have to embed it in the class as an object of its own. And even then I couldn't use it in place of it's parent.

A pseudo OOP might be possible in C, but C isn't designed for that and doesn't do a good job supporting it.

Don't get me wrong, I like C... But it's not object oriented.

Sometimes you can treat things as objects, but that doesn't make them objects, they don't comply with the standard OOP concepts.

[[h2o]]

Method and functions are not the same thing. A method has access to the members of a class. A function requires you to pass a pointer to the "object" (structure) which actually adds to overhead.
I found this interesting. First of all I have never seen that definition to separate function and method, and second I am not sure I understand where this overhead comes from.
If we look at python, callig an object method actually tags along the object as the first argument. I am not sure how C++ does it, but passing some kind of object reference pointer to the function seem like one plausible way to do it? Anyone knows where to read about it? Compiler theory is really not my strongest subject :)



As far as abstraction and encapsulation goes... There is no "private" or "protected" keywords in C... It's harder to ensure that a module will be used correctly. Neither has Python, and that doesn't seem to stop people. ;)

[CptPicard]

Despite what some on here like to suggest, C is a good starting language, in that there are a only few fundamentals, and it scales up nicely.


This is probably the strongest point going for C as a learning language for those who are serious about programming. Read Kernighan&Richie (the definitive C language reference) which is mercifully short and concise and you're good to go. The language itself is really simple, as soon as you get past the idea of pointers.

C++ on the other hand is just awfully complex as a language. You need to learn a lot about not only language syntax, but a lot of best practices, such as how to work with different value passing semantics, which quickly bring you to copy constructors, which can even bring you to reference counting very soon if you're working with large objects which must not waste time and space doing deep copies... and that's just something I ran into pretty soon after just starting with C++ ;)

[Wybiral]

;3166242']I found this interesting. First of all I have never seen that definition to separate function and method, and second I am not sure I understand where this overhead comes from.
If we look at python, callig an object method actually tags along the object as the first argument. I am not sure how C++ does it, but passing some kind of object reference pointer to the function seem like one plausible way to do it? Anyone knows where to read about it? Compiler theory is really not my strongest subject :)


Neither has Python, and that doesn't seem to stop people. ;)

IMO, Python isn't a completely object oriented language either... It picks and chooses.

The overhead in pseudo "objects" in C comes from this...

function(ptr_to_object)

vs

object.function()

The first is the only way it's possible to create an "object" in C with a method. The reason it has extra overhead is because "ptr_to_object" is not known and must be passed to the function. It's minimal... I know... But the second one already knows where "object" is, along with all of it's members and methods.

An object using lots of methods (especially when it's methods call it's other methods a lot) will cause more overhead in terms of passing memory around. It's not much, but it will add some overhead unless you are conservative with it's use.

Once again, inheritance is also a problem in C. Creating a truly generic base class in C would require lots of (void*) and might not be portable (some machines store C's structures different... Sometimes the spacing between data is padded to align properly... This would make accessing data in two different structures impossible with the same code, thus no chance in multiple inheritance without heavily embedded structures and a mess of passing around pointers).

The whole point of OOP is to allow for maximum code reuse and minimum need to understand the inner workings of the objects you are using (you should only need to know the interface, not the actual implementation). I just don't see this happening in a low level language like C where the point of using it is to have control over those details.

But once again... I am a C programmer too, and I know that it has it's perks, but not in the area of OOP and generic code.

[pmasiar]

This is probably the strongest point going for C as a learning language for those who are serious about programming. Read Kernighan&Richie (the definitive C language reference) which is mercifully short and concise and you're good to go. The language itself is really simple, as soon as you get past the idea of pointers.

K&R "Big Blue C" is excellent book - but for experienced programmers, it is useless for beginners. You repeat mistake what many experienced programmers do, but beginner need different kind of book - they don't know the "semantic" of loop, so hinting on syntax will not help them.

> C++ on the other hand is just awfully complex as a language. You need to learn a lot ...

C++ is OOP. Similarity with C is deceiving and superficial. Many C hackers expect it be just "better C", and are not prepared for paradigm shift with OO. In terms of memory management, C has (very simplified) stack (automatic) and global static variables. C++ adds heap for object instances - *BIG* difference.

[pmasiar]

methods = functions (are they not?)
abstraction = done by any library (libpurple can be used to connect to a jabber server and such)
encapsulation = is also done in C ...

No, no, and no. OOP (http://en.wikipedia.org/wiki/Object-oriented_programming) is hard, but after couple years you will get it :-)

Methods are functions firmly bound to object instance. So my new subclass can inherit some methods, and override others (same name, but different code). OOP magic will make sure, that you don't need to add code in superclass when you override method in subclass, and right code will run. This in main difference between function and method, and it is *very* important for big projects.

Also, very important is that every class makes its own namespace - you can have function with same name (and different code), doing things in custom way for each object. Without help of encapsulation, you would have many more global variables and global functions, and you will have to call special class-specific variant of function for every object.

[pmasiar]

IMO, Python isn't a completely object oriented language either... It picks and chooses.

Not sure what do you mean. What OOP functionality is missing in Python? I can argue that Pyhon is even more OO-oriented than Java, because Python allows for multiple inheritance (more than one superclass).

[slavik]

Not sure what do you mean. What OOP functionality is missing in Python? I can argue that Pyhon is even more OO-oriented than Java, because Python allows for multiple inheritance (more than one superclass).
so does C++, but the Java devs decided against multiple inheretence (diamond of death) and against operator overloading.

and lists act weird if you inherit them in python

[pmasiar]

and lists act weird if you inherit them in python

again, what exactly? or is just a FUD?

[slavik]

again, what exactly? or is just a FUD?
class A has a list

class B inherits from A
class C inherits from A

B and C are declared, but for some reason the lists they have is exactly the same one (change list in B and it changes in C). I believe this was the problem. Please note that I did not run into it personally.

[Wybiral]

Not sure what do you mean. What OOP functionality is missing in Python? I can argue that Pyhon is even more OO-oriented than Java, because Python allows for multiple inheritance (more than one superclass).

I take it back actually, I just read about python's "__" for private data. So I guess it can encapsulate better then I thought it could!

I could have swore it had no type of "private" features but I guess I learn something every day.

[pmasiar]

I could have swore it had no type of "private" features but I guess I learn something every day.

You are quite right, Python does not have "private" keyword, prefixing with underscore (and double-underscore) is just a convention and it does not prevent from accessing the attribute by determined evildoer (but double-underscore does name mangling, so it behaves like "private"). The approach Python developers have is - "we are all consenting adults". Don't sleep in my bedroom because I asked you not to - not because I have a shotgun.

So if you really, really need to reach deep in and use attributes supposed to be private, yes you can - and because *you* broke the rules, *you* should be prepared to face consequences. But sometimes it is the only practical way which works: "practicality beats purity."

[pmasiar]

class A has a list

class B inherits from A
class C inherits from A

B and C are declared, but for some reason the lists they have is exactly the same one (change list in B and it changes in C). .

list is class attribute or object (instance) attribute?

Anyway, defining double-underscore prefix (__listname) in A makes it private, so if B inherits, it will get own copy.

It is called "name-mangling", Google knows more details, I did not need to use it yet. :-)

so IIUC, everything works OK, you just need to use right idioms. :-)

[Noah0504]

Okay, so, I thought I would post this here since I've already started a thread about me beginning C programming. I pulled out the first volume of C for Dummies last night and was reading through. Today I thought I would try out a few examples just so I could test compiling under Linux (I forgot the book only covers a Windows or DOS enviornment).

Anyway, I'm having a problem with how the book teaches me to setup a basic application. Something as simple as the infamous "Hello World" application will not compile right. This is how the book displays the code:


#include <stdio.h>

void main()
{
printf("Hello World!");
}

Well, the GNU compiler doesn't like that code much. So, I hoped on Wikipedia and used the sample they had. It looked like this:


#include <stdio.h>

int main(void)
{
printf("hello, world\n");

return 0;
}

GCC really liked this code and compiled with no problem. Well, now I want to know how I'm suppose to learn C, when the book I have doesn't give me code that abides to standards.

[Jessehk]

Well, now I want to know how I'm suppose to learn C, when the book I have doesn't give me code that abides to standards.

In my (limited) experience, the few things that are usually not updated in books on C are...


main() should return int. Not void, not nothing (which used to default to int), but int only.
A function that takes no arguments, for example, foo, should be declared as foo( void ), not foo().


Hm...now that I think of it, that's it. I'm sure other people could add to this. :)

[Modred]

The only real difference between the two examples is the return type on the main function. In all of my C/C++ programming classes, we've been taught to use an int return type for main and, assuming everything works as expected, return 0 at the end of the program.

Some compilers (gcc for one), prefer this to any other scheme and you should use it unless you have a very good reason not to. Other compilers, such as Microsoft's Visual C++ (and possibly Borland? I'm not sure on that one), will allow the void main style. Many textbooks designed for use with MSVC, for example Deitel & Deitel's C++: How to Program, will use the void declaration in many places (at least in older editions, I haven't seen anything newer than the 3rd edition).

In short, just use int main() { ... return 0; } everywhere the book uses void main() { ... }. There may be some other disparities, but they shouldn't be too difficult to overcome.

I've never heard an opinion on foo( void ) versus foo(), but I've always used the latter and had no problems with MSVC or gcc (on both x86 and PowerPC) so far. I can't really say which is better.

[DavidBell]

The overhead in pseudo "objects" in C comes from this...

function(ptr_to_object)

vs

object.function()

The first is the only way it's possible to create an "object" in C with a method. The reason it has extra overhead is because "ptr_to_object" is not known and must be passed to the function. It's minimal... I know... But the second one already knows where "object" is, along with all of it's members and methods.

I don't think this is quite right, my understanding is by the time the compiler has made it's vtables and stuff

object.function()

becomes

function(this)

that's why if you try a function pointer to a public method it usually doesn't compile - there is a hidden class* argument in them so the definitions don't match. static members are OK because they don't have the hidden argument.

To me encapsulation is the big thing that separates OO languages.

DB

[slavik]

I don't think this is quite right, my understanding is by the time the compiler has made it's vtables and stuff

object.function()

becomes

function(this)

that's why if you try a function pointer to a public method it usually doesn't compile - there is a hidden class* argument in them so the definitions don't match. static members are OK because they don't have the hidden argument.

To me encapsulation is the big thing that separates OO languages.

DB
I have to agree with you.

another thing that adds to OO complexity are virtual functions (in Java, all functions are virtual by default)

[Wybiral]

I don't think this is quite right, my understanding is by the time the compiler has made it's vtables and stuff

object.function()

becomes

function(this)

that's why if you try a function pointer to a public method it usually doesn't compile - there is a hidden class* argument in them so the definitions don't match. static members are OK because they don't have the hidden argument.

To me encapsulation is the big thing that separates OO languages.

DB

My mistake, you're right about C++ at least... I did some investigation:



class example
{
int example_member;
public:
void example_method(int value)
{
example_member = value;
}
};

int main()
{
example example_instance;
example_instance.example_method(10);
return 0;
}


After being compiled and cleaned up so it's easier to see:



_example::example_method:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %edx
movl 12(%ebp), %eax
movl %eax, (%edx)
popl %ebp
ret

main:
pushl %ebp
movl %esp, %ebp
subl $36, %esp

movl $10, 4(%esp)
leal -8(%ebp), %eax
movl %eax, (%esp)
call example::example_method
movl $0, %eax
addl $36, %esp
popl %ebp
ret



So it should be about the same overhead with C and C++. At least for simple situations like that. I'm sure the compiler has some tricks up it's sleeve for more complex situations involving passing the pointer around that would make coding it in C a nightmare.

But like I said, that was minimal. The real problem is the lack of inheritance and encapsulation. I personally love inheritance as it allows you to reuse lots of code. Even a simple base object in C would be a stretch without hassling with a web of pointers.

And once again... I think some elements of OOP are possible in C, but not real OOP. It's just not designed that way.

[pmasiar]

Good article about how different languages will influence your thinking (and how to sell website written in high-level language like Lisp for $40M): http://www.paulgraham.com/avg.html



The Blub Paradox
...
Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one.



(which is, per Graham, Lisp. Python is only his second choice :-)

and here is some discussion so we don't have to repeat the sama arguments: http://c2.com/cgi/wiki?BlubParadox