Getting started FAQ

[Andre S. Veteran]

A recurring question on these boards is ? how do I get started in programming? ? Whether it?s choosing a programming language, finding tutorials or choosing an IDE, this FAQ is here to provide some guidance.

The FAQ assumes you want to start making desktop applications, with the most likely purpose of preparing for a Computer Science or Software Engineering degree. If you want to program websites, stop reading this and head over to w3schools.com. If you?re aiming for a particular domain (games, robotics, research etc), read this and then if any doubt remains please ask in the forums.

1) What programming language should I start with?

Short answer: Any widely used, general-purpose programming language can be a good choice. If that can be of any help, this author?s opinion is that you can?t go wrong with C#.

Long answer: What you?re looking for is a general-purpose programming language that:

• Will teach you elements common to most languages (statements, expressions, loops, conditionals, functions, objects, operators etc)
  
• Has a relatively clean syntax, logical design, and doesn?t lose you in low-level details
  
• Is popular and useful
  
• Has good IDE support so you can concentrate on learning how to program and not how to fight your way around crappy tools
  

Let's compare 4 of the most widely recommended languages:

C:

• Barebones, ?close to the metal? language, goes hand-to-hand with a course on computer architecture
  
• Ancient and eternal
  
• Hard to do anything graphical or even text-based (GUIs, games): C is primarily designed as a systems programming language
  
• Lacks such basic features as a string type, a container library, support for OOP, etc.
  

C++:

• All the advantages of C plus support for objects and generics, and better standard library
  
• Essential skill for any game programming position and in a wide array of domains
  
• Complex at the outset: hard to learn, hard to master
  
• Like C, it is mainly designed as a systems programming language
  

C#:

• Logical, reasonably simple
  
• Productive for GUIs, games, databases etc.
  
• Shields you from the OS (the .NET framework act as an intermediary), a good thing in many ways except for learning how computers work
  
• Not meant for writing device drivers or other such low-level code
  

Python:

• Highly intuitive and elegant, geared towards beginners
  
• Interactive prompt lets you learn by trial-and-error much faster
  
• IDE support (debugging tools, etc) not great
  
• Shields you from the OS and computer architecture (same as C# in that regard)
  

Other possible choices:

• Java (similar to C#; if you're on Windows, C# is the better choice)
  
• Ruby (similar to Python, but not as popular)
  
• Objective-C (popular for Mac and essential for iPhone development)
  
• Visual Basic (very similar to C#, but geared towards VB6 developers and beginners; many would say its peculiar syntax and legacy baggage make it an inferior choice)
  
• Functional languages like Scheme, Haskell, F#, Lisp, etc. which are interesting from a CS perspective but not that widely used.
  

2) What are some good tutorials on the Internet?

Classified by language:

C/C++

• cplusplus.com
  
• Cprogramming.com
  
• MSDN
  

C#:

• MSDN
  
• Yellow Book by Rob Miles - this is an excellent introduction to programming!
  
• C# Tutorial
  
• C# practical learning
  
• Dot Net Perls
  

Python

• Beginners/Non-programmers guides
  
• Official documentation
  

3) What software do I need?

One good IDE (Integrated Development Environment). What is available depends on your platform:

WINDOWS:

• For C, C++, C# and Visual Basic, look no further than the Express Editions of Visual Studio. They are free, stripped-down versions of the most widely used IDE in the industry. Check out the video tutorials there to get you started. If you are a student, you also might be eligible to a free, full version of Visual Studio through Dreamspark or MSDNAA.
  

The remaining tools are compatible for Linux and Mac as well:

• For Python, get the official runtime and IDLE from http://www.python.org/download/.
  
• For Java, both Eclipse and Netbeans are great choices. Be sure to check the great tutorials offered on both of these sites.
  
• An alternative for C, C++, C# and VB development is MonoDevelop. Frankly, Visual Studio trumps it on Windows, but it's pretty much the only way to do serious .NET (C# and VB) development on Mac and Linux, where Visual Studio is not available.
  

MAC:

In addition to the cross-platform tools mentioned above:

• For C, C++ and Objective-C, be sure to get Xcode. The recommended choice for developing iPhone applications as well.
  

LINUX:

In addition to the cross-platform tools mentioned in the Windows section:

• For C and C++, the best IDE is probably Code::Blocks, but there are several alternatives.
  
• Note that you don't necessarily need any particular IDE. Some people, especially Linux users (for some reason) prefer a "simpler" setup using just something like Programmer's Notepad (or even plain text editors like notepad. gedit etc) in combination with their favorite compiler (GCC, MSVC, etc).
  

You will still hear people recommending Dev-C++ around the net. To put it simply: don't use it.

4) Can you recommend some books?

For complete beginners:

C Primer Plus (5th Edition)

C++ Primer Plus (5th Edition)

Illustrated C# 2008

Beginning Visual Basic 2010

Learning Python: Powerful Object-Oriented Programming

How to think like a computer scientist: Java edition, C++ edition, Python edition, Ruby edition

Will add more later !

[Andre S. Veteran]

 

Doing anything graphical in C is only as hard as the GUI toolkit / library you use. As it probably is in most languages. For instance, creating a GUI in GTK isn't hard at all, nor is creating a terminal graphical interface using ncurses. Both are easy and powerful libraries which enable the programmer to create rich graphical user interfaces quickly.

 

It is relatively hard compared to installing Visual Studio and firing up the WPF or WinForms editor. No finding out about GUI toolkits ("What is a GUI tool-kit and why do I want that? I just want to make a game!"), no downloading the appropriate files, no linking libs, dlls and headers, no learning how to create a basic window, no learning how to wire up events programmatically, etc. There are so many less barriers of entry.

 

You are talking from the point of view of an experienced programmer for which out-of-the-box visual design tools are of little help because of the vast amount of things you already know. To beginners, it's a world of difference.

 

That's also incorrect. C is a general purpose high level programming language. It can be used for anything, from writing an accounts package with a rich graphical interface, embedded software on PLC controllers, Systems development, or writing an Android mobile app. It's completely flexible.

 

C is low-level compared to almost every other programming language someone could start with. It's only high-level in comparison to assembly, but no one's would even consider assembly as a starting language.

 

When someone says a programming language lacks basic features, what they're really saying is it doesn't have built-in things which exist in their own preferred language. Those things however, are often available in third party libraries as I mention below.

What I meant by basic features is features found in the vast majority of programming languages.

 

Note that my preferred language is F# and I didn't make any mention of it. C also lacks support for functional programming by the way: no tail calls, no sum types, no closures, etc.

 

And if someone wants a string type, there's nothing stopping them creating one. Just the same way as you might create any other data structure, be it a linked list, associative map, or tree. They're all containers.

 

Or if someone prefers something ready to go, there are plenty of modules written that can plug right in that will accomplish the same task. GLib for example implements most of those supposedly *missing features* including basic OOP.

 

That's why I'm saying C is low-level: because it doesn't include these things by itself. Just because it allows to code them, or that they are found in some external library, doesn't make C any less low-level. 

[FloatingFatMan]

In the modern world of programming, where most newbies to it just want to jump on the mobile app bandwagon, more modern high-level languages such as C# or Java are likely a far more suitable choice.  There's a much lower barrier to entry and way less righteous jerks on the various help forums who'll evangelize pure C as the only way to go and nothing else.

 

Of course, if your target platform is iOS, C is just about your only option.  Objective C at that. Ew.

[Andre S. Veteran]

Of course, if your target platform is iOS, C is just about your only option.  Objective C at that. Ew.

Except for sharing a letter in their names, C and Objective-C are only loosely related, by the way. Objective-C is more like C++ or even Smalltalk than C.

[vhane]

Except for sharing a letter in their names, C and Objective-C are only loosely related, by the way. Objective-C is more like C++ or even Smalltalk than C.

 

For what it's worth, Objective-C is a strict superset of C. That means that valid C code is valid Objective-C code. I'd say they are more than loosely related. The "ugliness" of Objective-C is tied to its relationship with C. The syntax would be cleaner if it didn't need to remain a strict superset of C.

[snaphat (Myles Landwehr) Member]

For what it's worth, Objective-C is a strict superset of C. That means that valid C code is valid Objective-C code. I'd say they are more than loosely related. The "ugliness" of Objective-C is tied to its relationship with C. The syntax would be cleaner if it didn't need to remain a strict superset of C.

I don't really understand this argument: C++ is nearly a superset of C and didn't end up with "ugliness" if you are referring to the syntax. What exactly is inherently there that would force such a thing?

[vhane]

I don't really understand this argument: C++ is nearly a superset of C and didn't end up with "ugliness" if you are referring to the syntax. What exactly is inherently there that would force such a thing?

 

Well, there is a thing called Objective-C++ too, which kind of compounds the problem.

 

For example, the use of the "@" character in language keywords and literals. @ was chosen because it is not used in either C, or C++.

 

Also, block syntax, with the following note by Apple regarding for the chosen syntax:

 

 

As Objective-C and C++ are both derived from C, blocks are designed to work with all three languages (as well as Objective-C++). The syntax reflects this goal.

[snaphat (Myles Landwehr) Member]

Well, there is a thing called Objective-C++ too, which kind of compounds the problem.

 

For example, the use of the "@" character in language keywords and literals. @ was chosen because it is not used in either C, or C++.

 

Also, block syntax, with the following note by Apple regarding for the chosen syntax:

From a C superset point of view they could have done any type of syntax they wanted to for the language as long as it didn't run afoul of C. Seems that it is largely the result of trying to avoid being incompatible with C++ syntax on top being a C superset based on their explanation.

[vhane]

From a C superset point of view they could have done any type of syntax they wanted to for the language as long as it didn't run afoul of C. Seems that it is largely the result of trying to avoid being incompatible with C++ syntax on top being a C superset based on their explanation.

 

In the case of blocks, yes. In the case of @, well, even being a superset of C forces that. C++ can reserve keywords that would otherwise be valid C identifiers because it does not attempt to be a strict superset of C.

[snaphat (Myles Landwehr) Member]

In the case of blocks, yes. In the case of @, well, even being a superset of C forces that. C++ can reserve keywords that would otherwise be valid C identifiers because it does not attempt to be a strict superset of C.

Obj-C has various keywords that don't begin with @ and break compatibility with C codes that use the names. There is no reason why they couldn't have done that with all of the keywords. Seems to me they just did it to differentiate various compiler directives from other types of keywords.

[vhane]

Obj-C has various keywords that don't begin with @ and break compatibility with C codes that use the names. There is no reason why they couldn't have done that with all of the keywords.

 

I'm struggling to come up with a code example. It seems to me that you couldn't call Obj-C a strict superset of C if that were the case.

 

 

 

Seems to me they just did it to differentiate various compiler directives from other types of keywords.

 

I think we're getting closer. And why were these implemented as compiler directives instead of built into the language?

[snaphat (Myles Landwehr) Member]

I'm struggling to come up with a code example. It seems to me that you couldn't call Obj-C a strict superset of C if that were the case.

Easy: id, inout, nil, byref, byval (there are others, i don't know off the top of my head). It's not a strict superset, everyone just says that because it is almost true. Who cares if you end up having to change c code names in an unlikely scenario anyway? It's really a silly thing to worry about in most cases.

 

I added nasty address space keywords (__global, __local, etc.) in a compiler at one point on a project I was on because "nice" keywords conflicted with some library code we were using. Eventually, my colleague was like "stop using those keywords no-one likes them because they look horrible and we aren't going to have many issues anyway because we will never be reusing much existing code". He was right, so we switched to global, local, etc. proper and just modified the library code we had instead. At the end of the day, how many people are compiling existing C libraries using obj-c? And how many libraries would have issue with keywords? Probably not much in either case.

 

I think we're getting closer. And why were these implemented as compiler directives instead of built into the language?

Well they are built into the language: they are just compiler directives that are part of the language, right?

[vhane]

I see. Would it be more fair to say that it's the fact that Obj-C is implemented as a thin layer on top of C that informs the way it looks then?

[snaphat (Myles Landwehr) Member]

I see. Would it be more fair to say that it's the fact that Obj-C is implemented as a thin layer on top of C that informs the way it looks then?

It's is possible. Maybe the compiler directives are straightforward to do transforms or something. Along those lines, I just searched for a second and someone said the obj-c language extensions were initially implemented using the C preprocessor. Perhaps at the time they were simpler and doable using that.

 

Disclaimer: I do not know if that information is correct.

[vhane]

It's is possible. Maybe the compiler directives are straightforward to do transforms or something. Along those lines, I just searched for a second and someone said the obj-c language extensions were initially implemented using the C preprocessor. Perhaps at the time they were simpler and doable using that.

 

Disclaimer: I do not know if that information is correct.

 

Yeah, I was just reading the same thing, and have just stumbled upon eero, a dialect of Obj-C which also supports drop in C and C++ code. So it seems that it's really the initial implementation of Obj-C that informs the way it looks. It kind of just grew from there.

 

This conversation has gotten me interested to dig deeper. Sorry for going way off-topic though!

[snaphat (Myles Landwehr) Member]

Yeah, I was just reading the same thing, and have just stumbled upon eero, a dialect of Obj-C which also supports drop in C and C++ code. So it seems that it's really the initial implementation of Obj-C that informs the way it looks. It kind of just grew from there.

 

This conversation has gotten me interested to dig deeper. Sorry for going way off-topic though!

That's a sad reason to keep it like it is though. I guess it is too late now. eero does look much better in comparison.

[Andre S. Veteran]

I don't really understand this argument: C++ is nearly a superset of C and didn't end up with "ugliness" if you are referring to the syntax. What exactly is inherently there that would force such a thing?

Oh, I intensely disagree with that. C++ wouldn't have headers, for once, if it wasn't for compatibility with C. It also wouldn't have two almost identical keywords for creating a class (struct/class), and many such strange things.

[snaphat (Myles Landwehr) Member]

Oh, I intensely disagree with that. C++ wouldn't have headers, for once, if it wasn't for compatibility with C. It also wouldn't have two almost identical keywords for creating a class (struct/class), and many such strange things.

I was contrasting C++ to Obj-C to show that being a superset to C doesn't force the ugly (hard to read) syntax of Obj-C, so what is there to disagree with? It appears to me that you are making a side argument that C++ is ugly itself because it inherited headers and quirks from C. Sure it inherited those things, but that's neither here nor there w.r.t. what I was said regarding Obj-C syntax, and it's a matter of opinion whether the quirks make the language ugly. To be perfectly honest, someone could argue that the syntax of Obj-C isn't ugly (hard to read) (note: I would never do this myself), but that doesn't change my point, that it being a superset of C doesn't force the language to have the additional syntax that it added that many people consider ugly.

[Andre S. Veteran]

(...) but that doesn't change my point, that it being a superset of C doesn't force the language to have the additional syntax that it added that many people consider ugly.

I wasn't really following your discussion, sorry.

[IronManMark20]

Great post! I agree entirely. I would however suggest that you change your suggestion from the express editions of Visual Studio to the Community Edition, which is basically Visual Studio for FOSS projects or individual developers. It also has integration with the Visual Studio addons. I would use it if I couldn't get Visual Studio Pro through DreamSpark .

[Andre S. Veteran]

Yes the post needs an update, I keep thinking I should do that from time to time. Will do eventually