Learning C with the Amiga

[falemagn]

lou_dias wrote:
falemagn wrote:

Self-descriptive code makes code beautiful.

I agree.  I know you weren't addressing me, but VB code is VERY self-descriptive.  C, not so much.  Please reference my code.  No flames intended.

I gently refuse to comment on that in this thread. Feel free to open another thread. :-)

[Piru]

@falemagn

What's more, too many comments clutter code. I want to see the code, I've grown a sense of aestethic towards code, so much that even if code I write works, and does so well, I keep adjusting it till it looks "beautiful", in the same sense as a well written and thought out mathematical equation can be "beautiful".

Self-descriptive code makes code beautiful.

Spot on! My heart bleeds when I see badly indented or formatted code, or something that is done overly complex way while simpler and more obvious code would be possible. I want to manually recode it just to make it more pleasing to the eye (and faster to execute, but that often is the consequence of the beatification anyway).

I often spend hours reading thru code written by others and at the same time review it, but it's more like reading a novel than labouring. Occasionally I do spot a bug and fix it, but most often I just look out for neat code snippets of code or for some fresh ways to implement some particular task. Programming is constant learning, and while I've programmed for over 20 years now, I still learn new things.

This is no language thing, I did the same with assembler already.

I guess this is the definition of a geek of a sort. Oh, and sorry for the OT,  again. ;-)

[AJCopland]

@falemagn
Ok, just so we're clear I agree with pretty much every point you've made.

The misunderstanding comes from the line:

The only things that require comments are algorithms, but the more self-documenting code you are able to write, the better.

Which in my haste this morning I totally missed. I'd personally extend that to include classes, structures, the usage of templates and a few other bits n' pieces that trip people over.

The idea of self commenting code is good, and all your points seemed valid, but having helped people through very well "self documented" code I still prefer to place comments to at least give them a secondary perspective. I also remember being a junior coder lost in "self documented" code and cursing the black heart of whoever wrote it for NOT leaving comments! So usually before a complex method I'll give a few lines description of the purpose of that method, the expected ranges and/or condition of it's inputs and expected outputs. It just helps people see what you're intention was.

I'm currently working on a project that has been outsourced to my company. The only comments in this code base are around equations in the physics library. Even though I've been doing this for a good 11 years now an undocumented interface is merely a hassle, but to someone else it's a quagmire that hinders development and can encourage lazy development practices.

Whilst C is a very precise language it isn't most of our coders "first" language. Over here that's English and so when people read my beautiful code :-D I like to tell them my purpose in writing it as well...

... plus comments give Babelfish something to work with, there's nothing worse than receiving a code base entirely with Japanese comments, variable and function names :crazy:

Andy

[Jupp3]

In my opinion there's far more to document what's mentioned here...

Obvious stuff, such as function input & output value descriptions and their possible limitations. What kind of values functions should NOT be used with (even if it's practically impossible to end up with such values in CURRENT project (thus no need for error checking in that project), I've sometimes just copypasted some function to new project, just to find out that it doesn't work becouse I use values slightly different than I should)

Also, I consider some kind of changelog (what was broken and when, you know :-)) code documentation

Oh and last but not least, BUGS. Sometimes you just can't find a bug (but know a workaround), maybe some API you use has some nasty bug you can't fix. Personally I sometimes keep not-so-well-working code in my project for a while before starting to fix it to a better form - Maybe the whole idea isn't as great as I though (can't know before I try it for a while), or I just lack time to fix it for time being, and leave it for later. And thanks to documentation, I have one excuse less for forgetting it :-)

[Cymric]

mel_zoom wrote:
lou_dias:

"It's these quirks that make it not a good language for beginners. Maybe if she ever learns a second language (C++ doesn't count), then she'll see the light at the end of the tunnel."

Hmmm.

You seem to think that I am lost in a dark tunnel. Im not - C seems quite straightforward so far. Whats this "light" am I supposed to C? :-P

" C is a language with few rules. How do you write structured code when the language has no uniform structure within it's design. "

It seems quite structured to me.

The problems are not what you think they are, and will only surface once you begin to construct bigger programs which cover, say, more than 25 K of source code. Then you will find that the parsimonity of C can become a hindrance rather than an asset:

- there is no automated memory management, forcing you to keep meticulous tabs on what your program does with what memory---and believe me, this is much harder than it looks
- type checking is enforced by the compiler and not the language
- string handling pretty much sucks: all you have is an array and a few library functions like strcpy() and strlen()---writing code which does a lot of string processing is not fun this way
- there is no bounds checking on arrays, so you can easily do 'int a[10]; a[10]=9;' and then try to find the cause of these spurious crashes of your program
- there are no standard libraries defined by the language to do network I/O, control graphic subsystems, offer standard data structures, and so forth
- there are no facilities for threading, coroutines, and the like: this is advanced stuff, which you can happily forget about
- and a LOT more.

The picture I'm trying to paint here is that C is an exceedingly basic language offering very little programming comforts or standardisation. You must provide quite a lot of extra layers to keep your programs managable, and none of these contribute to the actual program you want to write. You require a reusable code library which does all this boring stuff so you only code this once, test it to death once so that you're sure it's rock-solid and nuke-proof, and then use it more religiously than a fundamentalist clings to his scripture. But even that is not so easy as it looks because you now face the problem of modularity---breaking up code over various separate parts---and C's approach is rather basic.

In this regard I agree with lou_dias that C might not be the best language to learn to program in. It's not that the basics are difficult or in any way 'wrong': it's that once you master the basics that you are exposed to a lot of bare machinery you can really do without. Strangely enough, books and tutorials never cover this particular aspect...  :-P

[mel_zoom]

Hyperspeed:

"Mel: Are you Karlos' secretary?"

No. Is that the only IT role you can imagine a woman working in?

"Why does your Mazda link take me to a mammogram page?"

It isnt a Mazda link, its a link to a page that generates advertising money from your visits that in turn is used to provide free mammograms for those less well off. There are several other good causes on the same site that you can click on too.

[CannonFodder]

mel_zoom wrote:
Hyperspeed:

"Mel: Are you Karlos' secretary?"

No. Is that the only IT role you can imagine a woman working in?

"Why does your Mazda link take me to a mammogram page?"

It isnt a Mazda link, its a link to a page that generates advertising money from your visits that in turn is used to provide free mammograms for those less well off. There are several other good causes on the same site that you can click on too.

In which country?

Mammograms are free in most ¨1st world¨ countries.

[Louis Dias]

In that case, the USA is not a 1st world country.
Healthcare costs are quite a political debate around here.

[CannonFodder]

lou_dias wrote:
In that case, the USA is not a 1st world country.
Healthcare costs are quite a political debate around here.

This is way OT, but ¨It is un-American to have communist healthcare¨

[Sys_64738]

lou_dias wrote:
In that case, the USA is not a 1st world country.
Healthcare costs are quite a political debate around here.

USA is a great country, very advanced in technology and science.

But I really can't understand why you don't have a "public" health system.
Don't you think that human health (as education, etc.) should be rights for everyone??!?

[Louis Dias]

OT:
I am Portugues born, American raised.
I see this country with clear eyes.  It has many problems that foreigners don't see and I'm not a blind loyalist like many seem to be.

The problem with this government is that politicians also have business interests.  There should be a law separating the 2.  That is the root of many woes.  Everybody is in it for money and not for what is right.

[Jupp3]

- there is no automated memory management, forcing you to keep meticulous tabs on what your program does with what memory---and believe me, this is much harder than it looks

and believe me, I have done it, and it isn't THAT hard.

Actually I like it better than trying to guess what would be freed and when (Java garbage collection, for example)

- string handling pretty much sucks: all you have is an array and a few library functions like strcpy() and strlen()---writing code which does a lot of string processing is not fun this way

Weird. Last time I checked there was stuff like character searching, string searching, string compare, string copying and joining etc.
Are you sure it's the same string.h we're talking about?

Of course you might need some more "advanced" stuff in few projects you make, but you can do pretty much with those functions, and they're useful for creating your own.

While we're discussing strings, one tip:
Never do for(i=0; i

- there is no bounds checking on arrays, so you can easily do 'int a[10]; a[10]=9;' and then try to find the cause of these spurious crashes of your program

Most likely becouse there isn't difference between dynamic and static memory allocations. And memory allocations is what strings are. So in some cases it would work, in some it wouldn't.

- there are no standard libraries defined by the language to do network I/O, control graphic subsystems, offer standard data structures, and so forth

Not every system is similar. Many systems don't even have any graphics abilities at all, or they differ a lot. How would you create an uniform graphics api, that can draw for example AGA planar graphics and 32bit true color graphics?

Not really a feature, but this is one thing I really like about C. It doesn't try to force you to use some certain functions for (f.ex) graphics. You can just pick one that works best for your project, or do one of your own. You can use system-dependant API (DirectX, Direct3D) or one that's cross-platform (SDL, OpenGL), the choice is yours, not the choice of the developers of the programming language, you use.

- there are no facilities for threading, coroutines, and the like: this is advanced stuff, which you can happily forget about

Just like earlier, this is highly system dependant stuff. Some systems support threading, some do not. Different threading implementations are, well, different. Some offer more options than the others, so what kind of common API would you create?
Again, C doesn't force any particular solution you. you can pick any you like. Most of them "fit in" C code very nicely.

[Cymric]

*Sighs*. Of course I could have known I was going to be misunderstood. The point I was trying to make is that although C might be flexible (which is your point), as a [size=18]BEGINNING CODER[/size] you will find yourself thrown into the deep end once you leave the last page of your 'Learn C in 24 hours!' book. Keep those words [size=18]BEGINNING CODER[/size] in mind when reading my response please, and don't see it as a critique of the language---although one is forced to admit that if one has written a few projects in Python, or Ruby or Pike, C seems awfully messy and exposed.

That was my official answer. Now as to my unofficial one, which I will not debate further, because it does not cover what I meant to convey.  

* Pointer stuff is prone to errors, no doubt about it. If you've been able to code a general n-dimensional matrix allocator without the code barfing up once (which is the kind of memory allocation I had in mind), then I bow to you, my Master, and will come train with you to learn the ways of the Force.

* String handling via IS messy if you've grown accostumed to simple things like 'a = a + ", world!";'  With first you'd have to allocate the memory to hold the longer char *a, then copy it over with strcpy(). That's a whole lot of extra typing just for something simple as string concatenation. And that's just the beginning. Look up the capabilities of Python's string module if you want to have a useful set of routines which are not provided by ! Of course, you can easily write them yourself in C---but that was my original point.

* Your reply to my array-out-of-bounds mistake is silly: it doesn't matter if the array is dynamically or statically allocated. You are always poking around in memory you are not supposed to be poking around in. There is no language-supported checking on this type of error, which was again my point. Perhaps you are not such a good teacher of the ways of the Force after all...

* As to the system dependent stuff: If I want to code something which uses threads, and has to run on an Amiga, Windows, and Linux, I'd have to write separate threading modules for use with each operating system. Doable of course. But if I were to use Pike or Python or Java, I have but one way of writing that code to worry about, which (you guessed it) was my point. I'm not saying that the implementation of said languages on said OSes is the same (it's not) or easy (which it's not either)---but for the beginning coder it sure would be a lot easier if it were just all standardised, right...?

[Piru]

Pointer stuff is prone to errors, no doubt about it.

With correct typing I don't see this as a particular problem. There are several coding practices that reduce the change of making mistakes like that. Sure, it is well possible to screw up with pointers, but other languages have these aswell. I don't see this in any way weakness of C language.

You are always poking around in memory you are not supposed to be poking around in. There is no language-supported checking on this type of error, which was again my point.

There are tons of very nice standardized string libraries that provide dynamic and flexible string handling. You're not forced to use them however, the language doesn't enforce anything on you. Which is the point Jupp3 tried to make, I believe.

As to the system dependent stuff: If I want to code something which uses threads, and has to run on an Amiga, Windows, and Linux, I'd have to write separate threading modules for use with each operating system.

Well if you insist. I'd just use POSIX Threads library and be done with it.

C is nice since it doesn't restrict or limit you in any way if you prefer it that way. Still, you can use some very high level libraries that make your life very easy. The choice is yours, not something enforced by the language itself.

I'm not saying Python, or Ruby or other language sucks, these do have their applications. I say: Use whatever tool that fits your task. For me, C is the tool of choice.

[Jupp3]

as a BEGINNING CODER you will find yourself thrown into the deep end once you leave the last page of your 'Learn C in 24 hours!' book.

So what? Just use libraries that are suitable for beginners. Examples of such would be (imho) SDL and OpenGL.

But indeed that IS a problem. Many "beginner books" only have simple maths, basic structures, argument handling (overall, shell-only stuff) - all that while there are relatively easy ways to actually get (for example) graphical output of what you can calculate in your code!

I admit, "not being able to see what I could calculate" was maybe my biggest problem when I started coding in C, so in the beginning I just used a CU Amiga tutorial as base. It had code, which could actually draw pixels in window :-o - didn't understand most of it back then, but I managed to make it "do something I could see"

Soon that expanded to something, that should draw sierpinski triangle in a window (and later it actually DID draw that, once I replaced if(a=1) etc. with if(a==1), later switch-case, obviously)

Second problem was that I was using StormC back then, and it wouldn't compile much example codes I had. Later I just replaced it with gcc and separate text editor, and suddenly most of my problems just disappeared :-)

Since then it was OpenGL, then a bit of SDL and I noticed I had all features (and more) I always liked in AmosPRO, without all the problems.

Your reply to my array-out-of-bounds mistake is silly: it doesn't matter if the array is dynamically or statically allocated.

Consider following code (as code it sucks, but highlights the problem):

char *chr=malloc(atoi(argv[0]))
chr[10]='a';
There's no way compiler would know what size allocation ends up, so it can't warn about out-of-bounds access.

EDIT:
Maybe you meant that code should be checking bounds every time data is accessed, and compare it to the size of allocation? (thus forcing additional slowdown to all memory read & write operations)

Well that indeed can be a problem for beginners (especially considering how C does indexes, a[max] -> 0<=index
Again imho something, that shouldn't be forced on everyone. But I admit it, it can be a small problem for beginners.

[koaftder]

c may be a pain for dealing with strings withouth a nice string lib but at least its not like vb.net on opening a file handle:

FILE * bla = fopen("c:\koft\pov.c","w");

vs

Dim bla As New System.IO.FileStream("c:\koft\POV.c", System.IO.FileAccess.Write)

(;