• Please review our updated Terms and Rules here

Decided to start learnig C

Although I also consider myself a beginner (I'm a musician by profession), I will add my own thoughts.

I think an important reason for choosing one programming language or another is the preferred (or desired) programming paradigm. And that obviously translates into the way you think. (Or vice versa: The way you can think results in your choice of programming language.)
For me, OOP is a more natural way of thinking about problems.
On the one hand, it is very abstract, because it allows you not to think too much about hardware. On the other hand, it is very specific, because it allows you to model a problem using objects. Which, of course, is not always needed. Anyway, I have a choice.

The second thing. It is much easier for me to find a hole in the roof in the cpp code than in c, because I know who is responsible for what and where to look for it.

Although OOP can be approximated in c, imho c ++ in that case is the better choice.

And a little bit of the exotic at the end. In the early 1980s, 8-bit computers began to appear in communist Poland - mainly in some schools. Few could afford a home computer.
In those days, the computer press in Poland (but also my math teacher) promoted LOGO as a much better language than BASIC, as it taught "good habits" and avoiding the "spaghetti code".

Before my parents bought me my dream Atari 800xl, I was going to a friend who had zx spectrum. To this day, I remember the thrill when the turtle drew what I had imagined on the zx spectrum screen!
 
It's a good point about thinking.

Back in the late 1960's, a fellow was offering seminars in what, IIRC, he called the "Pride Method". The basic idea was simple--before a line of code was scribbled on a coding pad, one defined precisely what the output and input of a program would be. That included page layouts and input formats. Then a list of steps, including all data structures that would be needed to get from the input to the output, along with a list of possible "gotchas" and what would be done with them. The guy's whole point was that if you were thorough enough in the specification, the code pretty much wrote itself.

It's still good practice. As in so many fields, music included, discipline is the key.

C++ is a lousy fit for low-level hardware applications, such as device drivers. It's a great fit for user applications, if not a bit verbose. Template writing is an art all within itself. I don't find a well-written C program to be any more difficult to understand than a well-written C++ program.

I don't use a chisel to drive screws, nor a screwdriver to shape wood. Every language has its uses. I'd no sooner write a simulation in C than I would write a device driver in SIMSCRIPT.
 
I agree with what Chuck is saying about C vs. C++.

One thing I will say about C is that, like assembly, there are no training wheels. This isn't a critique of the language at all, but rather a warning: It is easy to hang yourself quickly in C/C++. This is something to think about when learning it - go slow - step the code - watch what it does. Get past all those bugs however in its performance can be stellar.
 
Not at all--"playing around" with is not exactly real programming. You can write a "hello world" program in dozens of langauges; e.g.,

'Hello World!'

Runs in APL just fine, but doesn't even begin to scratch the surface of the language.

It's "playing around".

Well then, I guess I'm still "just playin' around". This is a hobby for me. If I wanted to make a career of it, I should have started A LONG TIME AGO! ;) These days, I spend my free time doing what I enjoy and trying to stretch my abilities, mentally and physically. So, Yes, this is supposed to be fun AND difficult. But not so difficult that I start yelling at the wife about it!

Greg
 
How about Pascal as the first language to learn!!!!!

Back in my school days, they used to tell us that Pascal was
the best "structured" language to learn about programming...

ziloo :mrgreen:
 
Well then, I guess I'm still "just playin' around". This is a hobby for me. If I wanted to make a career of it, I should have started A LONG TIME AGO! ;) These days, I spend my free time doing what I enjoy and trying to stretch my abilities, mentally and physically. So, Yes, this is supposed to be fun AND difficult. But not so difficult that I start yelling at the wife about it!

Greg

Which is really why you ought to try Processing. It's the closest modern equivalent I could find to the old Turbo Pascal or BASIC platforms. Java is used extensively in high schools and universities for teaching CS and is close enough to C syntax as to not be disconcerting if you are already somewhat familiar with that. Kind of the modern replacement for Pascal. One might say that Python is the modern equivalent of BASIC (using some creative license here). Having both available under Processing provides some flexibility in language choice. Many examples are provided as both Java and Python versions.

In Processing, the code isn't called an application, it's called a sketch - a quick, lightweight program to carry out a task, usually graphically oriented because that is the most interactive and rewarding for beginning (and seasoned) programmers. Much of the boilerplate code is hidden away which often presents a barrier to entry by convoluting the process of just getting something running. The large collection of example code can be used as a basis for your own, or just modify the examples. Lots of online videos and documentation at your fingertips.

A nice sandbox to play in.
 
How about Pascal as the first language to learn!!!!!

Back in my school days, they used to tell us that Pascal was
the best "structured" language to learn about programming...

ziloo :mrgreen:

Back when Pascal was making waves and "structured programming" was the latest buzzword, I did some research and explained what it was all about to a co-worker. His response? "You mean what good programmers have been doing since there have been computers?". Yeah, pretty much. One could, I suppose make the point that Algol-60 was the first structured higher-level language--and nearly nobody uses Algol today. I think Pascal's (and Modula-2's) day in the sun has come and gone.
 
Depending on what the ultimate goal is here and if you're already familiar with "a language" (BASIC is good enough) another decent sandbox for playing with C might be to buy one of those Arduino starter kits that comes with a protoboard and a bunch of LEDs/sensors/whatever and learn via exposure to the Arduino IDE. (The language for which is C. The Arduino library includes a number of primitives that make it not quite a *standard* C environment in terms of input/output, etc, but all the normal data and control structures are there.) There's a huge library of exercises and reference sketches out there to work with and if you blow up anything you can get a box of three knockoff Arduino Nanos for about $15 from Amazon and not shed a tear. The AVR hardware is a very minimal (but fast) 8-bit CPU so it does make you think about things like choosing the optimal data types (bytes verses integers, etc), and it's even pretty easy to program in assembly, so if the goal is to figure out how to get closer to the hardware you could do worse.

(I'm mostly a Python programmer in "real life", but I was able to pick up enough about the AVR's assembly language to do real work with it in a couple afternoons, and the Arduino IDE makes it not particularly difficult to embed short assembly routines directly into a C program.)

Obviously this probably isn't the way to go if you want to learn C for "systems programming"; there's not really an "OS" involved here.
 
Amazing response to the OPS's thread from the professionals and hobbyist alike. What I think he wants is some general tips and encouragement on where to start. Instead he's been getting a steady flow of what others deem necessary and important and a load of guidance concerning prerequisites. I think he knows that he probably won't be making the mortgage payments (if any) from the C++ adventure, but like a lot of us, just wants to know something about it. Speaking for myself, I've got the software now and I have a book. My plan is simple or maybe not; I'm going to attempt to take a simple BASIC game and port it to C. I'll play with it and if it's like my last endeavor with Linux, I may lose interest fast.
 
Amazing response to the OPS's thread from the professionals and hobbyist alike. What I think he wants is some general tips and encouragement on where to start. Instead he's been getting a steady flow of what others deem necessary and important and a load of guidance concerning prerequisites.

I should be very clear. I've already made several posts on this thread. But I should make it unequivocal.

Simply the OP should do whatever he wants, but he should stick with C. If you start chasing languages without doing anything, you'll never stop, and, in the end, won't get anything much done either.

C is fine. Work with it, get your things done, put some time in to it to learn the things you love and hate about it.

In college, they (at least used to) have these "computer languages" class. Basically it was a quick introduction to a lot of languages within one course, vs a dedicated course on Pascal or FORTRAN.

And while the languages course gave some exposure, it really wasn't enough. It was enough to give a little taste, but that taste tended to be bitter because the languages were different enough that all the student would do is stumble through them just to get the projects done.

Many, many people learned to hate Lisp in these courses. I can see someone spending 2 weeks with Python and grousing about the semantic whitespace, and other warts on the language rather than its benefits.

Which is why I feel that if someone wants to learn to program, they simply need to pick a language, ANY language (any real language, vs the novelty languages, and I honestly don't recommend assembly, but...), dive in head first, and stick with it. Because so much of programming and computer science has nothing to do with the language.

So, in this case, the choice has been made: C. Run with it, have fun with it, do some projects, get some work done, get some successes out of it.

Later, that experience can be used to make an encounter with another language that much more rich. "Oh, C does that, C doesn't do that, why would I want to do that? This is better, this is worse."

If I were doing C on a legacy PC, I'd pick a 386, and I'd pick Turbo C for the IDE, and the SMALL memory model, and do all I can with that (which is a lot, skies the limit). The small memory model gives you 64K of code and 64K of data, without having to worry about segments and NEAR and FAR pointers and all of that. Tiny model shares the code and data, but doesn't offer much of a difference in the actual coding experience, so may as well get the extra memory space for free. Plus all of the code written for the SMALL model will pretty much "just work" if you compile it under Linux (which doesn't have to worry about the early PC memory models). Why muddle your head with details like the memory model when you're just trying to get a linked list to work.

You can do that with the other memory models, it just changes the default pointer style, but, again, why worry and obsess over those details at the juncture.

The debugging experience on the 386 is just that much better to be worth while if you're not going to be pedantic on processor, and Turbo C is a wonderful IDE.
 
I guess it depends on who you are with Languages, I had my time with C in Class and apart from the Lecturer, I had problems with Coding problems in written sentenses and I think I would still have those problems.
If a problem arrised in BASIC or there was a certain problem with someones code in BASIC, I'd have a higher chance of solving it particularly if it had a mathemathical problem to it, because I could simply type the formula and get an answer and if it was what I was looking for then great, otherwise I'd eventually work it out. Not all BASIC stuff, though breaking it down into a more structured look has work for me particularly when dealing in Short BASIC stuff with Long Lines. I have Pascal to thank for that.

On a modern system, Python seems to be the language which offers that area to type in a forumula and return a result though, I'm not sure if I've seen C with that kind of offering. Though I've seen people learn C and not know anything else, so maybe by the time I came along and knew BASIC, Pascal, Delphi, some Logo & Z80 Assembly I needed to commit to C and forget everything else.
 
I picked up the later (next) edition of a C text I consumed long ago. It was cheap, and brought back memories. I haven't completed it, moved on to other projects, but plan to pick it up pretty soon. I have this behemoth Northstar server box that's been sitting here for too long. The Dimension. I think I would get a kick out of porting Minix to it. Therefore I'll need to brush up thoroughly on whatever knowledge I had (had and forgotten a lot of). I tend to do things the hard way. I could probably muddle through the source code, which I don't even need to do really. But when it stops chokes on something I'm going to need to understand why. The D* isn't a PC compatible, although it hosts plug in PC motherboard cards. It's uP is an 80186. When I got it it was somewhat banged up. The hard drive bracket suggests the h/d itself took a very sever beating. I haven't the guts to just plug it in and see what happens. I'm not hopeful. And I don't want anything to catch on fire. My Tandy 4000 did recently. A capacitor exploded, part of it flew across the room, and the remaining stump kept burning until I blew it out. And it wasn't even my birthday.
 
Generally the consensus is (or was, possibly not in this thread though) that it's best to learn a language like C without having to deal with the mechanics of an IDE (Integrated Development Environment). IOW write your program in a text editor, issues simple command line instruction, w/switches or parameters possibly, which will result in the creation of an object file (assuming no errors). Which would then require linking, another simple command. All of this can be automated with batch files. When writing assembler programs years ago, I wrote the batch file so the newest iteration of my program would overwrite the earlier version, working mu way through the error correction process.
 
Have you tried any of the free courses available from Stanford, Harvard or Coursera? They aren't particularly effective for learning practical programmin skills, but they do give you a good primer on the main languages and they're quite a bit more entertaining that a textbook. The computer science primer course from Harvard gives a good intro to C I believe. Those courses tend to give you access to good learning resources, which is their real value for people with basic programming skills.
 
I think you heard everything needed to know from the "Higher Powers" ......(not me!).
You can write a nice code :hammermon: and get some output :killcomputer:and show us on this thread....


ziloo :mrgreen:
 
I'm assuming the OP is familiar with elementary concepts in computer programming if he/she has coded in BASIC. If so, learning C is a natural next step. I would not recommend it to folks who have never programmed before. Something like Python is better suited for that.

C's most powerful tool is that of the data pointer. It can do great things and cause great havoc if done wrong. If you can figure those out along with intermediate concepts like structs, linked lists, and recursion, it opens up a ton of doors to problem solving and programming. Whats nice about knowing C is that there are a ton of languages with "C like" syntax (Swift, Java, C#) or directly derived from C (C++, Objective-C, both object oriented extensions) that you can quickly pick up. Having a ton of existing code to play with and compilers on just about every platform is nice too.

The "flavors" of C mentioned here mostly come from the standard libraries compilers include. The most well known of these is glibc (GNU gcc, *nix) and the Microsoft C Runtime (msvcrt, Visual C++). C libraries back in the day were like the wild west due to the lack of standards, so be careful.
 
gcc has quite a number of backends, not just x86. I use it for ARM as well as x86-64.

Another C to consider that was somewhat popular in its day was D.J. Delorie's DJGPP for writing 32-bit code on DOS without the bother of going to the Windows API.
 
Just glad I never tried to learn C as the first language.

A BBC micro was a great place to start. Fairly straightforward basic and the ability to use procedures got the mind working in structure. Once that was learnt, the embedded assembler and the well defined OS calls were next. Wrote a text to speech program in assembler by re-directing the keyboard interrupt , point is from Basic to operating system assembly calls is fairly easy all in one machine with some good books to back it up. Taught me a lot, sat there with the Basic manual open and Ian Birnbaums assembly book, all I needed :)

C's pointers would have confused me if I didn't have some sort of understanding of how things worked.

Would recommend one for kids even now.
 
A C pointer is hardly different from an assembly pointer with the exception of the compiler enforcing typing. It's a pretty fundamental concept in CS
 
Pointers are darned useful in the real world. FORTRAN for years tried to avoid them, but finally gave in.

In the BASIC that I did for an 8085 system, I invented the "BASED" keyword to denote an array or string that had no initial address assignment.

You could then say "BASE A$ AT FOOF$(3)" whence A$ would refer to the third element of FOOF$. So pointers without explicit pointers.

I might note (patting myself on the back) that this was long before the Microsoft C++ "__based" declaration.
 
Back
Top