Role of "C" programming language for a beginner?

[narayan594]

Please any one help me with your suggestion......

I need a reason for why C.

[Andre S. Veteran]

The less obfuscation the better in my opinion. Anyway, it doesn't really map to hardware any differently than C derived languages. Pointer arithmetic is perhaps the exception.

Without understanding basic programming concepts, how can one hope to solve problems or make best use of the resources available? Ignoring essential notions such as data structures won't help anyone in the long run. Start at the beginning, and start simple. That's how I've always approaching learning in general.

It's like telling someone to learn the subjunctive mood before they even have a grasp of the basic grammar of a written language.

If someone's goal and focus is solely mathematics or related field then I'd agree. But the OP is clearly interested in programming languages and the role of C.

And don't forget, there are many C libraries available that one can plug into. The C standard library itself is just another library. Glib for instance provides support for object oriented style programming, as well as commonly implemented data structures.

I'm not sure why higher level languages like C# would be any better for "algorithms considerations", unless you're talking about having built-in stock data structures and functions, all of which as I mentioned above are available in libraries.

Besides, how will a beginner learn anything if the language does everything for them. Or what happens when they decide that the built-in functions don't satisfy program requirements. Then they're really stuck. Learning the fundamentals, including creating basic data structures and algorithms is what computer science is all about. Spoon feeding does them a disservice and discourages critical thinking.

You keep mentioning data structures and algorithms as if it was a particular trait of the C language that it allows one to write its own implementations. The fact is that you can write your own data structures and algorithms in any language, that many universities actually use languages other than C to teach data structures and algorithms (mine used Java), and that C is not particularly fit for this task, with no list comprehensions, iterators, higher-order functions or explicit tail recursion. The set of features supported by C closely follows hardware-level abstractions but hardware-level abstractions do not happen to be very useful abstractions for expressing data structures and algorithms. I think teaching basic programming concepts through the window of C teaches more how to work around its lack of high-level abstractions than how to translate real-world problems into a computable representation.

 

The fact that most languages have richer standard libraries than C is not an obstacle to learning data structures and algorithms as any proper CS course will obviously forbid usage of existing implementations in assignments. If anything, a quality standard library gives a good example to follow when implementing your own.

 

I have implicitely advised against learning something like C# (or Java or C++); I have advised using a simple language that has a low barrier of entry and REPL support. Python is a popular choice; the MIT has used Scheme for a long time as I referred to.

[astropheed Veteran]

You said yourself that by the time you learnt Python you already knew most of C. 

 

I never said that at all, that's just how you interpreted it. By the time I learned C I already knew Python, Javascript (jQuery) and PHP at a high level. I also had quite a bit of experience with other programming languages such as Go, Lua and Java.

 

If I had started with C, I can almost guarantee I'd have also ended with C. But that's just me. People learn differently and this is just my advice. I didn't like C, I still don't like C and I'll never like C. It would have made me think it's all like C and frankly it just isn't. Python and Javascript are actually quite fun to program. I even like PHP, which is odd to many.

[simplezz]

True, but depends on your goals. Self-enlightenment is always a good thing of course (and one of the few times I'll agree with you).. working under a time-crunch to get a job done so you can pay the bills is something else entirely. It's not the perfect language for every job.

I agree. I often write programs in both Java and Python, and while they're good tools, they're not a perfect fit for every task, and neither is C. Horses for courses and all that. Although I do find myself reaching for C first, but that's probably mostly down to preference.

Still, for a beginner, I'd say the role of C as programming language is an important one. Both because of its simplicity and because it teaches the fundamentals of how software works.

[simplezz]

I don't really know basic outside of doing a few macros in excel, but I've heard tale that learning Basic at all makes you a worse programmer. I'm not sure how true that is.

Yes, that's quite probably the worst advice possible. Learning basic, especially as a first language, will teach all kinds of bad habits. It's also so different to C that it'll just end up confusing a beginner and putting them off altogether.

[Andre S. Veteran]

Yes, that's quite probably the worst advice possible. Learning basic, especially as a first language, will teach all kinds of bad habits.

Such as?

[Max Norris]

Yes, that's quite probably the worst advice possible. Learning basic, especially as a first language, will teach all kinds of bad habits. It's also so different to C that it'll just end up confusing a beginner and putting them off altogether.

Oh gawd I can attest to that. First one I ever picked up was some variant of BASIC back in the 70's.. transitioning to anything else was jarring to say the least, next one was C under Microsoft Xenix and Modula-2 just because and went from there, BASIC did me no favors. There's a lot of similarities across many of the languages.. except BASIC. That's way out in left field all by itself. (This is ye olde BASIC mind you.. VB.NET is nowhere near as bad as "classic", they cleaned up the language quite a bit, different animal entirely.. not that it's my favorite mind you as it's not.)

[simplezz]

that many universities actually use languages other than C to teach data structures and algorithms (mine used Java)

We're not talking about a CS course where writing such things is mandatory. There's little motivation for a beginner learning a higher level language to rewrite data structures and algorithms. They probably won't even know what they are, they'll just be calling built-in functions. So they're missing out on learning the fundamentals of software programming.

and that C is not particularly fit for this task, with no list comprehensions, iterators, higher-order functions or explicit tail recursion.

None of which is necessary and yet more complexity to burden the beginner.

The set of features supported by C closely follows hardware-level abstractions

You keep repeating that. Which set of features?

The fact that most languages have richer standard libraries than C

That matters little when third party libraries exist.

If anything, a quality standard library gives a good example to follow when implementing your own.

I guess you haven't seen an STL implementation then ;)

I have implicitely advised against learning something like C# (or Java or C++); I have advised using a simple language that has a low barrier of entry and REPL support. Python is a popular choice; the MIT has used Scheme for a long time as I referred to.

Answer me a question. Which is the simplest language, C or Python? Also take into account Python's rather unique white space indentation.

[astropheed Veteran]

Answer me a question. Which is the simplest language, C or Python? Also take into account Python's rather unique white space indentation.

 

Python.

[simplezz]

Such as?

I don't know about newer incarnations (vb.net etc), but in the past, things like lack of modular programming enforcement. No static typing and so forth. Goto abuse. I've seen some horrific VB code. It's very forgiving, too forgiving, and that can lead to bad habits and sloppy code.

[Andre S. Veteran]

We're not talking about a CS course where writing such things is mandatory. There's little motivation for a beginner learning a higher level language to rewrite data structures and algorithms. They probably won't even know what they are, they'll just be calling built-in functions. So they're missing out on learning the fundamentals of software programming.

If their goal is to learn the fundamentals of CS, then they can do that in any language. If their goal isn't to learn the fundamentals of CS, then why would they choose C?

 

None of which is necessary and yet more complexity to burden the beginner.

... no more necessary than explicit memory allocation, header files, linker errors, pointer arithmetic and having to compile the entire program every time (lack of REPL). The difference is that one type of complexity is mostly accidental and useless to CS purposes, the other introduces generally applicable concepts and encourages to think in a functional way. By the way, tail recursion is necessary to write recursive algorithms that cannot blow the stack. C explicitely discourages this.

 

You keep repeating that. Which set of features?

The set of features supported by the C language: its data types, evaluation model, control structures.

 

Answer me a question. Which is the simplest language, C or Python? Also take into account Python's rather unique white space indentation.

Python has more features than C, but these features can be learnt more incrementally, meaning that Python effectively appears simpler. Also, the presence of an REPL greatly encourages exploratory programming and learning through trial-and-error. For example, the canonical "Hello World" program in Python can be achieved by opening the REPL and typing

 

print "Hello World"

This code contains nothing more than a function name and its argument. The student gets immediate feedback on what he has written including underlining any mistyped character.

Whereas the equivalent task in C requires:

1) Creating and saving a text file somewhere

2) Writing the following code: 

 

#include<stdio.h>
int main(){ 
    printf("Hello World");
}

This code contains mostly noise and will be very mysterious to a neophyte.

3) Opening a command prompt

4) Invoking the C compiler on the text file with something like

 

g++ hello.cc -o hello

This reports errors by providing a line number and column, which the student then has to look up in his text file.

5) Running the executable thus produced

Which is simpler?

[simplezz]

... no more necessary than explicit memory allocation

FILE *f = malloc ( sizeof ( FILE ) ); 

vs

MyClass mc = new MyClass ( ... );

I don't see a lot of difference.

 

header files

Namespaces, imports.

 

linker errors. pointer arithmetic

Which errors? Missing library errors? You can get them in other languages too. Pointer arithmetic is quite simple once you get the hang of it. You have references etc in other languages as well.

 

and having to compile the entire program every time (lack of REPL).

I guess you've never used a Makefile, GNU autotools, or Maven before then?

 

By the way, tail recursion is necessary to write recursive algorithms that cannot blow the stack. C explicitely discourages this.

Most of the time recursion is a poor solution anyway. Iteration is often superior and makes for cleaner and more predictable code.

 

The set of features supported by the C language: its data types

typedef struct {
  
  int   a;
  char  b;
  float c;

} Object;

vs

public class Object {

  int   a;
  byte  b;
  float c;

};

A lot of difference there..

 

evaluation model, control structures.

Such as?

 

Python has more features than C, but these features can be learnt more incrementally

Really? So you don't have to learn procedural and OOP at the same time and all that entails? I could say the same about C. You can learn it incrementally as well ;)

 

meaning that Python effectively appears simpler. For example, the canonical "Hello World" program in Python can be achieved by opening the REPL and typing

print "Hello World"

This code contains nothing more than a function name and its argument. The student gets immediate feedback on what he has written including underlining any mistyped character.

Whereas the equivalent task in C requires:

1) Creating and saving a text file somewhere

2) Writing the following code:

Oh Really?

 

 
$ c-repl
> puts ( "Hello World!" );
Hello World!

or:

$ gdb
(gdb) printf "hello world\n"
$1 = "hello world"

3) Opening a command prompt

4) Invoking the C compiler on the text file with something like

 

g++ hello.cc -o hello

This reports errors by providing a line number and column, which the student then has to look up in his text file.

Which is simpler?

Acually it's gcc. g++ is for C++. But anyway, they should be using automake, then it's only one command - make, which can be done inside of Vim without leaving the editor.

I was talking about the language itself. C is clearly simpler in terms of keywords, concepts, paradigms, syntax, library, etc. Regardless of whether you learn it incrementally, there's still much more to learn and it's easier to get overwhelmed.

[astropheed Veteran]

Regardless of whether you learn it incrementally, there's still much more to learn and it's easier to get overwhelmed.

 

What did you learn first?

[Torolol]

use "GOTO" the unconditional branch, those who get used to it are better at creating program/drivers with low level language as Assembly for ARM or x86.

but again the last fruitful usages of assembly was on Gameboy Advance games.

[seta-san]

gets you used to 'c' syntax which is widely used in other languages such as 'c++' java, javascript, c#, etc..

gets you used to functional programming before expecting you to get familiar with more abstract ideas like objected oriented programming or some other abstract ideas that you find in c++..

it'll force you to really learn about pointers, referencing, dereferencing, etc. c++ and other languages in a lot of ways helps you avoid the headache but in that same breathe sort of denies you the knowlege and experience.

getting into more advanced things it'll teach you about the stack and the heap and memory management

[vhane]

gets you used to functional programming before expecting you to get familiar with more abstract ideas like objected oriented programming or some other abstract ideas that you find in c++..

 

I think you mean procedural/imperative programming.

[simplezz]

What did you learn first?

Pascal and Smalltalk. Admittedly not the best of starting languages, but it was a uni course so.. If only I could go back and talk some sense into myself :D

[Max Norris]

Pascal and Smalltalk. Admittedly not the best of starting languages, but it was a uni course so..

Pascal was fun, used to use Turbo Pascal back in the DOS days for a few years, FPC later off and on out of nostalgia.. think my old Xenix setup had it too but never used it there. Kind of a messy language though, and God help anyone who gets chained to Embarcadero's version of it. Missed out on Smalltalk though, although I know it heavily influenced languages that came later.

[Andre S. Veteran]

FILE *f = malloc ( sizeof ( FILE ) ); 

vs

MyClass mc = new MyClass ( ... );

I don't see a lot of difference.

I said that C relies on explicit memory management and that higher-level language do not. I don't know what you're trying to accomplish by showing two statements that don't do that same thing at all, i.e. one reserves a portion of memory and returns a pointer to it, the other creates an object of a particular type, which is two different levels of abstraction. 

 

As for data types, the data types supported by C are those supported directly or that have direct translations to hardware-level instructions (int, IEEE754 floating point, arrays), whereas higher-level languages also support things like arbitrarily sized integers (bigint), decimal floating point numbers, unicode strings, opaque reference types, closures. The control structures are those that can have very simple translations in assembly (if, while, etc., all map to cmp/jmp instructions), whereas higher-level languages support control structures that may have more complex translations (generic pattern matching, iterators, computation expressions, etc). The evaluation model is strictly imperative, with no lazy evaluation, again mapping to how CPUs work rather than to more general abstractions.

 

I didn't know about c-repl, but the project seems to have been dead since 2008. gdb is a debugger and doesn't allow defining new functions AFAIK, so its use as an REPL seems very limited. I have never seen a C book or online tutorial that explained how to use these tools for exploratory programming. It certainly isn't a focus of the language.

 

The number of commands or tools used for building are not what I'm referring to - one still has to compile C code, somehow, to run it. The lack of proper REPL support adds substantial overhead to the learning process and to the feedback loop.

 

Saying that recursion is a poor solution most of the time... how??? It's certainly a poor solution in C, but it's often the best solution in functional languages and generally speaking in the immutable style that is generally a better fit in today's multi-core world. If we're talking about data structures and algorithms, recursion is everywhere. Tree structures are defined recursively (even in C) and therefore operating on trees lends itself naturally to recursive implementations. Sorting algorithms are more often than not, defined formally in a recursive manner. For example wikipedia defines quicksort recursively.

I was talking about the language itself. C is clearly simpler in terms of keywords, concepts, paradigms, syntax, library, etc. Regardless of whether you learn it incrementally, there's still much more to learn and it's easier to get overwhelmed. 

 

I think I've illustrated well how the simplest C program introduces many more concepts than the simplest Python program, i.e. includes, headers, function definition syntax, brace scoping, etc. There are more features in Python, but they can learnt in better isolation from each other. Furthermore, Python is simpler to work with due to first-class REPL support, and Python contains fewer stumbling blocks due to its very lightweight syntax and support for concise expression of list comprehensions, iterating over arbitrary collections and the like. This means that learning Python is more productive as it introduces more useful and generally applicable concepts.

[simplezz]

I said that C relies on explicit memory management and that higher-level language do not. I don't know what you're trying to accomplish by showing two statements that don't do that same thing at all, i.e. one reserves a portion of memory and returns a pointer to it, the other creates an object of a particular type, which is two different levels of abstraction.

You said explicit memory allocation was an unnecessary complication in C, or words to that effect by implication. My example was to demonstrate that in reality, there's not much difference in complexity, in terms of syntax and function calls, between malloc-ing a block of memory in C and creating an instance of a class in a higher level language. What the relevant functions / language constructs do is immaterial.

 

As for data types, the data types supported by C are those supported directly or that have direct translations to hardware-level instructions (int, IEEE754 floating point, arrays), whereas higher-level languages also support things like arbitrarily sized integers (bigint), decimal floating point numbers, unicode strings, opaque reference types, closures.

All of which at some point has to be reduced to machine code. I'm not sure what your point is here. The integral data types for most languages behave the same way. If C has less abstraction and executes quicker, that's a positive attribute.

 

The control structures are those that can have very simple translations in assembly (if, while, etc., all map to cmp/jmp instructions)

Any higher level language worth its salt should translate those same simple constructs (if/else, loop/while, switch), which are present in most languages, into similar machine code eventually.

 

whereas higher-level languages support control structures that may have more complex translations (generic pattern matching, iterators, computation expressions, etc). The evaluation model is strictly imperative, with no lazy evaluation, again mapping to how CPUs work rather than to more general abstractions.

Yet they still have similar simpler constructs, just like C. All of which can probably be reduced to the same cmp/jmp instructions.

Abstractions hide what's happening and complicate the thought process. That's why I'd never suggest someone start with an OOP language. I don't think that's suitable for a beginner who wants to learn how software and computers work.

 

I didn't know about c-repl, but the project seems to have been dead since 2008.

If you want something more modern and less hacky, then Cling (http://root.cern.ch/drupal/content/cling) would probably be a better solution. It's an interactive C++ interpreter, built on the top of LLVM and Clang libraries.

And don't forget there are also C shells available on *nix style OS' that allow the execution of inline C-like code.

 

gdb is a debugger and doesn't allow defining new functions AFAIK. I have never seen a C book or online tutorial that explained how to use these tools for exploratory programming. It certainly isn't a focus of the language.

That's true, but it does allow the loading of libraries and elf binaries. So it's easy enough to call a range of functions and play around with them. It's not a full REPL-like environment, but it's a good interface for experimentation without having to recompile and rerun programs.

As a very capable debugger, one can jump to different functions and code, as well as executing and examining arbitrary functions that have been loaded. GDB is very useful. Once you learn the commands, much like vim, it makes you a very efficient programmer.

 

The number of commands or tools used for building are not what I'm referring to - one still has to compile C code, somehow, to run it. The lack of proper REPL support adds substantial overhead to the learning process and to the feedback loop.

A programmer doesn't write a full blown program in a REPL, not that I know of anyway. It's for experimentation and testing, or at least, that's what I use them for. If I'm writing a real program, I'll use a text editor like vim, and some kind of build system that compiles only changed or added code, manages dependencies, and execute custom scripts. REPL isn't practical for such real projects.

 

Saying that recursion is a poor solution most of the time... how??? It's certainly a poor solution in C

Yes it's a poor solution in C in a lot of situations, not all. I've seen it misused often when iteration could have just easily done the job.

 

For example wikipedia defines quicksort recursively.

And if you look further down it states:

The disadvantage of the simple version (recursive version) above is that it requires O(n) extra storage space, which is as bad as na?ve merge sort. The additional memory allocations required can also drastically impact speed and cache performance in practical implementations. There is a more complex version which uses an in-place [Iterative] partition algorithm and can achieve the complete sort using O(log n) space (not counting the input) on average (for the call stack).

As I said, iteration is often the better choice. Functional languages are a whole different category.

 

I think I've illustrated well how the simplest C program introduces many more concepts than the simplest Python program, i.e. includes, headers, function definition syntax, brace scoping, etc. There are more features in Python, but they can learnt in better isolation from each other.

If your only ambition is to play around with a REPL, yes. If someone wants to write real python code that's executable and purposeful, no, because you're going to want to write modular code and the same kind of boiler plate things you mentioned like function signatures, white space indentation, imports, classes, etc.

[Andre S. Veteran]

You said explicit memory allocation was an unnecessary complication in C, or words to that effect by implication. My example was to demonstrate that in reality, there's not much difference in complexity, in terms of syntax and function calls, between malloc-ing a block of memory in C and creating an instance of a class in a higher level language. What the relevant functions / language constructs do is immaterial.

You showed two different statements that do not do the same thing: one allocates a block of memory, the other creates and calls an initialization method on a new object. The second statement does not equate to explicit memory management. Just because creating an object might be implemented by the compiler or runtime as allocating a block of memory from the process heap (which is far from necessarily the case, GCed environments generally just return and increment a pointer) does not make the two statements equivalent. The semantics of malloc is that it returns a pointer to a block of memory. This memory contains garbage and it is entirely up to programmer to do something useful with it. For example, the programmer might use it to store some data of a completely unrelated type, or the programmer might not even do anything with it. It is his responsibility to free this memory when he is done with it. This is not the same thing at all than a statement that returns an opaque reference to an object which lifetime is managed by the runtime. We're not only talking about two different levels of abstraction (one states the intent, the other a mechanism), but the mechanism here is just one possible, incomplete - and inefficient - way of implementing that abstraction.

As for namespaces and header files - not the same thing whatsoever, the first is a type qualifier, the second is a form of hand-written metadata to enable to compiler to treat each source file in isolation so it's purely a compilation mechanism; include directives create an implicit graph of inclusions and beginners inevitably run into multiple include and circular dependency issues, with their appropriate solutions - none of which are useful or generally applicable CS concepts, but accidental complexity of a specific language.

 

 

All of which at some point has to be reduced to machine code. I'm not sure what your point is here. The integral data types for most languages behave the same way. If C has less abstraction and executes quicker, that's a positive attribute.

You offered that other langauges also provide data types that map to hardware abstractions, but I nuanced that other languages also provide data types that do not map directly to hardware abstractions. It is a particular design choice of C to only offer data types that map to hardware abstractions. Thus C offers a level of abstraction that closely follows how hardware works. But this level of abstraction is not a particularly useful one for the purpose of introducing the topic of programming and computer science in general. Execution speed is largely irrelevant for teaching purposes. Just looking at the different areas of computer science, about the only one I could say that C is a particularly good fit would be Computer architecture and engineering. C has far too few concepts to be interesting to programming language theory, it's missing several common and useful abstractions for data structures and algorithms, doesn't contain any facilities to help with numerical analysis or computing theory, nevermind concurrency and parallelism, databases, software testing, etc.

 

 

Any higher level language worth its salt should translate those same simple constructs (if/else, loop/while, switch), which are present in most languages, into similar machine code eventually.

(...)

Yet they still have similar simpler constructs, just like C. All of which can probably be reduced to the same cmp/jmp instructions.

But that's irrelevant. Just because higher-level languages include constructs that are similar to ones offered by C does not make C a particularly good fit as a first programming language.

 

 

Abstractions hide what's happening and complicate the thought process. That's why I'd never suggest someone start with an OOP language. I don't think that's suitable for a beginner who wants to learn how software and computers work.

Well there's the crux of the issue. You're talking from the point of view of teaching computer architecture, and in this respect I agree that C would be a good fit, notably because C's level of abstraction is close to that of the hardware. I'm talking from the point of view of an introduction to programming and computer science in general, which includes countless topics aside from computer architecture; therefore I favor a language that will be as simple to learn as possible and teach generally applicable and useful abstractions to students that they can then apply to various fields and languages.

One classical introduction to computer science, and I've referred to it often in this thread, is the Structure and Interpretation of Computer Programs used at Berkeley and MIT. If you look at this book, you will see that it touches on many topics that one could not dream of approaching in an introductory course if the teaching language was C. It is able to provide a vast outlook in part because it uses the right level of abstraction to do so. Courses based on this method are notoriously hard but provide an extemely solid basis for the rest of the curriculum.

As for recursion: perhaps you missed that even the "iterative" version of quicksort is recursive as the quicksort procedure calls itself; only the partitioning is done iteratively. And you didn't address my point on tree structures which are at the basis of many typical data structures and algorithms. You seem to simply dismiss anything that C doesn't support as unimportant, back-handedly referring to functional languages as "whole different category" (what does that even mean?) and equating higher-level features with potential C implementations as if C was somehow the reference point of all programming languages. I understand that this is what you use in your daily work, but it's just another language, and there's little about it to make it attractive as a first programming language, apart from the low number of concepts; but if that's to be the only criteria, then assembly is even better because there are even less concepts in assembly - and you can make much of the same arguments you make about everything eventually compiling down to machine code and hiding what the computer is doing to justify using assembly. At that rate, even C is far from ideal.

Thanks for pointing out that there's an up-to-date C++ REPL, perhaps if it was adopted in more learning material it might make C more approachable for beginners.

[simplezz]

As for recursion: perhaps you missed that even the "iterative" version of quicksort is recursive as the quicksort procedure calls itself; only the partitioning is done iteratively.

The partitioning was my focus because it demonstrates that recursion can be an inferior solution to a problem, as was the case in the wikipedia quicksort example.

And you didn't address my point on tree structures which are at the basis of many typical data structures and algorithms.

I'm not disputing that recursion has a place, just that in many cases iteration can perform the same function without the worry of stack or performance issues.

You seem to simply dismiss anything that C doesn't support as unimportant

*OOTB yes. Because most of the things you say C is missing are available through third party libraries or drop in code files. An example would be Sqlite, which provides database support and comes in both shared library and amalgamation form. The same applies to common data structures and algorithms, if the programmer is inclined to seek stock solutions.

but it's just another language, and there's little about it to make it attractive as a first programming language

1. Simplicity. There's no large API or feature set to learn.

2. Lots of high level languages are based upon it in one way or another. So what you learn in C can be applied to a large number of other languages.

3. It teaches how to manage system resources properly.

4. Because it's so powerful yet completely general purpose, you can write absolutely anything in it, from operating systems to Android apps to embedded software.

5. It has universal compiler and standard library support across all major platforms.

apart from the low number of concepts; but if that's to be the only criteria, then assembly is even better because there are even less concepts in assembly - and you can make much of the same arguments you make about everything eventually compiling down to machine code and hiding what the computer is doing to justify using assembly. At that rate, even C is far from ideal.

Assembly is architecture specific and features cryptic mnemonic codes that don't resemble natural language. Hardly comparable with C or other high level languages.

Thanks for pointing out that there's an up-to-date C++ REPL, perhaps if it was adopted in more learning material it might make C more approachable for beginners.

REPL's have their use, but they're not a replacement for a proper editor and build system. That being said, it wouldn't hurt to make them more available as you rightly point out.

[astropheed Veteran]

I'm siding with Andre S. for most things but I agree with simplezz on the merits of recursion. Whenever it's possible to avoid recursion I do. In some places, like traversing a tree it's quite intuitive to use a recursive function but for most other aspects it's almost always better to use some iteration. It's just nice to not have to worry about the stack. 

 

Also, at some deep level I feel recursion is sloppy.

[Torolol]

well, chess alogirthm usually demands recursion,

on games that have finites moves like othello/reversi, using recursion would usually ensure the computer would win or at least draw.

[Andre S. Veteran]

I'm siding with Andre S. for most things but I agree with simplezz on the merits of recursion. Whenever it's possible to avoid recursion I do. In some places, like traversing a tree it's quite intuitive to use a recursive function but for most other aspects it's almost always better to use some iteration. It's just nice to not have to worry about the stack. 

 

Also, at some deep level I feel recursion is sloppy.

Recursion provides very elegant solutions to certain problems and is a vital technique for programming in a functional style. Because of the rise of multi-core and massively parallel computers, this is a very important topic today; most languages, even Java and C++ (but not C) now support functional programming to various degrees.

I'll answer in more detail later.

[Andre S. Veteran]

The partitioning was my focus because it demonstrates that recursion can be an inferior solution to a problem, as was the case in the wikipedia quicksort example.

And an iterative solution can be inferior to a recursive one, particularly if the problem is naturally recursive and writing an iterative implementations involves explicitely managing a stack that recursion manages implicitely. It is not generally the case that iterative solutions are superior, and in certain languages like Haskell, recursive solutions are sometimes the only possible solutions; in several languages, recursive solutions are more idiomatic than iterative ones.

 

I'm not disputing that recursion has a place, just that in many cases iteration can perform the same function without the worry of stack or performance issues.

These are only worries in C due to the particular semantics of C, not due to the nature of recursion.

 

*OOTB yes. Because most of the things you say C is missing are available through third party libraries or drop in code files. An example would be Sqlite, which provides database support and comes in both shared library and amalgamation form. The same applies to common data structures and algorithms, if the programmer is inclined to seek stock solutions.

Sqlite cannot compare to F# type providers or C# LINQ, to mention some actual language features that are helpful to database programming. And when I say language features that are helpful to data structures and algorithms I am not talking about libraries of ready-made data structures and algorithms, but support for abstractions such as iterators and list comprehensions to help in writing one's own implementations in a legible way.

 

1. Simplicity. There's no large API or feature set to learn.

2. Lots of high level languages are based upon it in one way or another. So what you learn in C can be applied to a large number of other languages.

3. It teaches how to manage system resources properly.

4. Because it's so powerful yet completely general purpose, you can write absolutely anything in it, from operating systems to Android apps to embedded software.

5. It has universal compiler and standard library support across all major platforms.

1. Simplicity, ok.

2. Most languages look like most other languages, and most concepts from most languages apply to most other languages, C contains relatively few concepts and even several of these don't apply in most other languages (such as its antiquated compilation model and explicit memory management), so that's not really a strong point of C.

3. Most languages have constructs for managing system resources, only difference in C is the need to do it for every single thing that's not stack-based and that's not necessarily what you want to focus on for a first programming language.

4. Lots of languages are general-purpose. Operating systems and Android apps and embedded software were written in Lisp and Java and C# etc.

5. If you're writing a device driver for some obscure router, then perhaps there's only a C compiler for that, but most platforms support most mainstreams languages in general, so that's not really an important consideration.

 

Assembly is architecture specific and features cryptic mnemonic codes that don't resemble natural language. Hardly comparable with C or other high level languages.

And C code is very cryptic when it comes to expressing concepts that it's not good at, for instance futures (which are supported by most programming languages today) would probably be a nightmare in C.

 

REPL's have their use, but they're not a replacement for a proper editor and build system. That being said, it wouldn't hurt to make them more available as you rightly point out.

Good REPL support largely negates the need to rely on a build system in the context of learning a language's syntax, playing with what the different statements do, etc., i.e. the kind of very small program that a student learning a first programming language might be doing.