Sign in to follow this  
Followers 0
Andre S.

Getting started FAQ

71 posts in this topic

While I'm evangelising C, I thought I'd disabuse those reading this thread of some misconceptions.

 

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.

 

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.

 

You are just making semantic arguments. "General purposeness" is unrelated to the notion that C was designed for systems programming and refers only to the notion that the language can be used to solve problems outside of a specific domain (contrasting with domain specific languages which were designed to solve problems only in a specific domain). For example, VHDL is a a hardware descriptor language that's only application is in designing electronics. HTML is a markup language that's only application is in describing web pages.

 

 

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.

 

The fact that you can link with existing libraries and tool-kits that provide additional functionality does not change the nature of the language. It doesn't mean that the language itself suddenly provides automatic memory management features and a built in expressive library providing higher-level functionality. Your argument is basically if you search for and bolt on all of this additional software that someone else wrote, C is potentially easier to work with than it would be otherwise. In the same vein, I can make the same argument for x86 assembly because I can link to and use the same 3rd party software that C can use.

 

 

It's not necessary to have string types, a container library, or OOP support in order to write software. Some in fact might view these *features* as unnecessary bloat which hinders performance and complicates the language.

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.

So what if it is not necessary? it's easier and a safer and higher-level than working directly with character arrays. How does your argument at all address the nature of C not being high level. You are just telling people to implement or search for 3rd party implementations of all of the missing functionality themselves.

 

What do you mean it is more difficult to write an word processor in C than it is in Java? I found word_proc.go() online and I just called that directly. Done! Easy as pie!

2 people like this

Share this post


Link to post
Share on other sites
 
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. 

1 person likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

(...) 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.

1 person likes this

Share this post


Link to post
Share on other sites

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 :D .

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.