Why C?

breadmonkey

I'm in 1st Engeineering and we've been doing some programming in C. Is there any reason to choose this language?

Thanks

Gone West

yes. Ive written java vbasic and c++, and I find c is fairly fast and stable. Dont get me wrong im no master 'grammer or anything, but it is the standard for creating windows tools, etc. You will see how useful it is against say vbasic as your course progresses.

Cake Fiend

It's fast, it's easy to learn, it's popular, it's portable, it has great depth, flexibility and power, it's been around for donkeys so it's well-known, there's tons of information and other resources (compilers, libraries, etc) available either commercially or free on the internet, some other very popular programming languages are based on it (C++, Java) so you can use it as a springboard for these languages, people will still be using it in years to come.

There are of course downsides to it (or rather things about it that have been improved upon by other languages), but all in all, C is a highly versatile language and a great one to get started with.

scojones

C is the language of the gods.

Mohanned

ross*k wrote:

I'm in 1st Engeineering and we've been doing some programming in C. Is there any reason to choose this language?

Thanks

Its the basics and most languages link up to it

bringitdown

http://www.cprogramming.com/whyc.html

Google: http://www.google.ie/search?q=%22why+C%22&hl=en&lr=&client=firefox-a&rls=org.mozilla:en-US:official&start=10&sa=N

Many arguments for and against, for students I think if you manage C you'll have gotten a great grounding. It is something I would look for in a hire, because you'll most likely emerge from C with some knowledge of low level programming.

Remember java's first compiler / VM was written in C.

Merrion

C punishes laziness and sloppy thinking so a course in C will make you a better programmer even if in real life you end up using a more high level language.

voxpop

Im not sure about engeineering and what you get up to (programming wise) but in software developement land - c is rarely used or required in my experience.
Languages that are used alot are Java,.NET(C#,VB.NET),Delphi,scripting languages (js/vbscript/php). These languages would all generally make slower executing code than c but with todays computers that isnt really a concern unless writing drivers/os kernels (;))/etc.

ressem

For programming close to the metal, C compilers and libraries are sometimes all that are available to you.

Gives you access and experience to memory addressing, heap, stack, registers, interrupts that are almost untouchable in higher level languages until things break badly.

On the other hand the standards committee update it at glacial pace, e.g. they don't add safer char array handling functions because they'd be a bit slower. So you end up having to write/research lots of stuff that's supplied at the start in other languages, confirming with your manager that you can use this or that BSD library.

kenmc

Angry_Penguin wrote:

Im not sure about engeineering and what you get up to (programming wise) but in software developement land - c is rarely used or required in my experience.
Languages that are used alot are Java,.NET(C#,VB.NET),Delphi,scripting languages (js/vbscript/php). These languages would all generally make slower executing code than c but with todays computers that isnt really a concern unless writing drivers/os kernels (;))/etc.

Would totally disagree with this statement. I am a Software Developer with 7 years experience, and the *only* language I use on a day to day basis is C. Occassionally I will go into assembler depending on what I need to do. The reason that I'm in C/ASM is that it's embedded SW - i.e. small footprint stuff typically with 10s of MB of ram - eg 16 MB, and an overall sw size of circa 4 MB flash. C++ would be too bloaty and Java would be both too bloaty and too slow running in these devices. C is an absolute must in my book as it teaches you all the important stuff that others eg Java and so on rely on eg pointers - they're abstracted out in Java, but still underneath. Also teaches you good manners like freeing when done with a malloc etc. AND it gets you down to register level and into the bones of the system.
If you want to write *user level* programs then you can get away with Java/C++ etc, and bloaty code is not such an issue, but if you really wanna understand how code works and how you can squeeze each and every little KHZ (yeah KHZ, not MHZ) out of a processor go down the C route.

voxpop

c is also the language that gave us buffer overflows and numerous other security exploits because the people using the language didnt understand the subject correctly. C doesnt teach you anything, you have to learn it yourself. Also if you delve deeply into most highlevel languages they also provide some sort of facility to get into heaps/stacks/pointers/etc.

High level languages mean you dont have to worry about pointers,memory allocation and deallocation, etc. Thats the point, these low level elements are abstracted away so the developer can concentrate on writing good code that does what its supposed to do.

TBH kenmc, im not recommending a high level language if you are building drivers ,writing os components, doing some types of embedded programming (although remember there are pleanty of java apps and games for mobile phones - this is fairly small footprint stuff) or anything that requires low level i/o and memory management. The fact is that today most companies (software dev companies) are looking for people with OO high level language skills and not C.

The original question was whether to choose C or not. I think the answer is - it depends on what you are going to be programming. If as an engineer you will be writing sorftware for controllers and other embedded devices then C is the way to go otherwise go for a more high level language.

kenmc

Ok, I take your point Angry Penguin regarding the buffer overflows etc etc, but I would still recommend that before anyone learns a high level language that they are exposed at least to some degree to a lower level one eg C, so that they will realise that there are things that are being looked after for them with C++, Java etc. i.e. you can't understand the benefits of something till you see the problems it solves.
Also it's not unknown for a compiler to make a fcuk up, esp if it's been ported over to a new platform etc, so it can be extremely beneficial to at least know that there are such things as memory leaks that can be investigated when the program starts going off into the boonies, and the code *looks* coherent.
Also, any tool is only as good as it's driver. What I'm terribly afraid of is people who have never seen C, only C++ and when they go out into the real world and have to write some C and given it's syntax similarity to C++ will not bother to investigate too much and hence not know anything about freeing memory,checking for null pointers, deferencing etc etc.

Edit :

If as an engineer you will be writing sorftware for controllers and other embedded devices then C is the way to go otherwise go for a more high level language.

Unfortunately in college you have no way of knowing what sort of programming (if any!!) you will be doing when you get out into the big bad world. They generally teach you several languages (I did pascal, C, C++, Java, Erlang, 68KASM), so that you get the hang of the practice of programming full stop, and once you are able to program in one language you will be able to learn other languages.

InkPot

I think perhaps the upshot of it all is that.. as a *student*, learning C is an excellent choice, regardless of what you may end up doing after graduation in terms of s/w dev. ( ie., user applications or embedded s/w dev. etc..) .. Learning a programming language that requires the most discipline first is always a good idea. It will make you a better programmer later even if you never actually use C again. Having said that, I would also recommend familiarising yourself (even on your own time) with an OO language (C++/C#/Java).... just because of the different approach you have to take when programming in them. Its a very useful string to have on your bow.

Cake Fiend

Considering the OP is in first-year Eng, it's pretty safe to assume that they'll be learning OOP later on (in fact, I'm surprised they weren't started off on Java TBH). IMO, learning C first will give a good framework for learning C++ or Java later.

HaVoC

Friend of mine is doing physic and instrumentation degree
He used:

C
Math lab
VB + ActiveX

Through out his studies he used these languages to talk to various instruments voltmeters etc over a serial port.
C allows you to get more control over things as it’s at a lower level. As c is at a lower level they probably teach it to make you understand what’s happening under the hood in the high level languages like Math lab & VB + ActiveX.

breadmonkey

Thanks for the replies everyone, even if I don't really understand some of the terminology

I doubt I'll ever do any programming after this year since I'll probably be going down the civil route. Or am I wrong?

scojones

Angry_Penguin wrote:

C doesnt teach you anything, you have to learn it yourself.

I don't get your point here. Are you saying that with higher level languages you don't have to "learn it yourself"?

C is being taught to first year college students because it introduces them to structured programming before they delve into the world of OOP - which is very good practice.

High level languages mean you dont have to worry about pointers,memory allocation and deallocation, etc. Thats the point, these low level elements are abstracted away so the developer can concentrate on writing good code that does what its supposed to do.

By "writing good code" do you mean well-structured, easy to read code? Or do you mean efficient code? "writing good code" is a massive generalization.

If you learn C, you'll gain alot more knowledge of how things work than you would with the likes of Java, VB, C#, et al..
You will be forced to learn how things operate at a low level, and your programs will be stable and efficient, they will not be bloated and slow.

Learning C before learning another language is a very good practice.

voxpop

sjones wrote:

Originally Posted by Angry_Penguin
C doesnt teach you anything, you have to learn it yourself.
I don't get your point here. Are you saying that with higher level languages you don't have to "learn it yourself"?

If you read the rest of the thread you will notice that some people claim that C teaches you important stuff and implies that if you start programming with C you will become a fantastic programmer. My point is that working with C doesnt automatically bestow any special knowledge on you - like every other language you have to work at it.

sjones wrote:

C is being taught to first year college students because it introduces them to structured programming before they delve into the world of OOP - which is very good practice.

I think you'll find that in many colleges these day, langauges like Java are taught to first year students,with C,assembly and the like being taught in second year.

sjones wrote:

By "writing good code" do you mean well-structured, easy to read code? Or do you mean efficient code? "writing good code" is a massive generalization.

Everyone knows what "good code" means (hows that for a generalization) - dont be so pedantic

sjones wrote:

If you learn C, you'll gain alot more knowledge of how things work than you would with the likes of Java, VB, C#, et al..
You will be forced to learn how things operate at a low level, and your programs will be stable and efficient, they will not be bloated and slow.

So everyone who learns C, becomes a great programmer :rolleyes: and you complain that I generalize!


I think ross*k is happy enough with the feedback, shall we leave it at that.

Pinhead

sjones wrote:

You will be forced to learn how things operate at a low level, and your programs will be stable and efficient

Wow, with C, your programs will be stable and efficient?! Yeah! Maybe with ten years experience... :rolleyes:

dent

The first language I learned in college was c then C++ then Java. Seems like a logical progression. C is fast and also handy for systems programming in say Linux.

scojones

DeadBankClerk

Angry_Penguin wrote:

High level languages mean you dont have to worry about pointers,memory allocation and deallocation, etc. Thats the point, these low level elements are abstracted away so the developer can concentrate on writing good code that does what its supposed to do.

The problem is that these are leaky abstractions:
http://www.joelonsoftware.com/printerFriendly/articles/LeakyAbstractions.html

bonkey

Thats a fabulous article dbc. Just read it.

Hobbes

People go on about java being slow. JIT actually allows you to run it at machine code level. Also the later JVMs will actually recode your application if it is running for a long time to optimize it for speed. Something that compiled exes can't do.

I've used a number of languages and I would have to say that C is not the best one to start off on. It is not an OO language. It is easy to write piss poor code in that is impossible to maintain. Some languages are bad in this way (Visual Basic being the worst offender).

If you are going low level I would recommend reading about ASM. It is unlikely that you would program in it (unless its device drivers) but you don't need to know C to do it.

Writing code in the industry is part of what language is best, speed and maintainability. The last one is a major issue. Companies are big into slotting in new programmers when others leave. Most work in development is maintaining code.

So go with a language that enforces good coding standards (not by punishing you at runtime), documenting and OO design.

Capt'n Midnight

Merrion wrote:

C punishes laziness and sloppy thinking so a course in C will make you a better programmer even if in real life you end up using a more high level language.

given a choice between two similar programs to do the same job one GNU / C and the other Shareware / Visual Basic , almost invariably the C one will be better in all areas apart from eye-candy.

tempest

Capt'n Midnight wrote:

given a choice between two similar programs to do the same job one GNU / C and the other Shareware / Visual Basic , almost invariably the C one will be better in all areas apart from eye-candy.

Assuming that you mean "an application written in" GNU / C ... then I agree with what you say (because you said almost ), but would you not agree that perhaps this is more to do with personality/dedication/philosophy/experience of the designers and coders than with the programming language which is used.

kenmc

Hobbes wrote:

I've used a number of languages and I would have to say that C is not the best one to start off on. It is not an OO language. It is easy to write piss poor code in that is impossible to maintain. Some languages are bad in this way (Visual Basic being the worst offender).

I would argue that an OO language is not the best one to start off on, because if you become accustomed to OO methodology you would potentially find it quite difficult to go "back" a step to something which didn't handle OO eg C.

There is no one language that can be called "better" than the others due to the limitations and experience of the programmer that is writing in that language - i.e. a master C programmer would be more than capable of churning out a more stable, secure program faster than a relative newbie in Java or C++ or whatever - it's very dependent on the one who wields the weapon, rather than the weapon itself....

In my opinion programming is an art more so than a science, (again related to who and what rather than what, hence why it's so difficult to say how long a module will take to write - depends on the writer) albeit a technical art. It is a complex thing to describe in minute detail to a basically dumb machine, what you want it to do. - e.g. how would you tell someone who lives in the jungle how to go about starting a car (assuming they spoke the same language) whats a key. whats the ignition??

It always goes back to first principles, and the language which can be used in the simplest way (not the same as the simplest language) should be used as a primer, and then the skills built upon. You can't understand how useful classes are until you have experienced not having them firstly. Once someone has an understanding of programming and the thought process behind it, then they can start to worry about how to write secure code. You have to crawl before you can walk before you can run.....

I've read some interesting articles on the whole art vs science debate also, but I can't for the life of me find them. I did find this though
http://fresh.homeunix.net/~luke/misc/knuth-turingaward.pdf
by Knuth which explains why he calls his book "The Art..."

damnyanks

Over the past 3 years (When I started college) I've gone from VB and Assembly in one year to Java and C#. Although the Java was of absolute crap standard... at least what we were taught did C# myself.

Started in another college and doing much better things with Java far more object orientated and we have recently started with C.

It is a pain in the ass for me
We have to use a dynamic array in C. Just so used to having collections already there in the API

I would never consider programming a art. Its a trade... at least learning how to do it. To do it correctly is a different story.

osmethod

Some teaching of C can be from a historical perspective. C was the choice language for the original unix operating system and is still the choice language for sys v/bsd type unix's today and windows oses.

Computer Engineering tends to look at systems from the systems own point of view. The teaching of C is, in my view, the closest language between systems and human communication.

With C you need to be able to understand the process involved for a given function to work. If you do not have an understanding of how the system works from its point of view it is difficult to understand how to go about fixing it if it breaks down.

For example: Within an operating system there is a "Memory Management" subsystem. When a program executes, various parts of the program are mapped into memory. The Os will initially create address space, for the program to execute in. This address space will have the program instructions and data loaded into it. A stack and a heap will be initialised. Stack being a LIFO data structure which stores local variables, functional calls, etc. The heap being a FIFO data structure primarily storing dynamic variables.

C is an excellent languge for this type of system.

Software Engineering tends towards higher level languages

For example: Visual Basic and Database programming on MS systems go hand in hand. Designing a database is more to suit real business processes as in storing company data in tables, designing user friendly forms and structuring queries upon that data. The underlying processes (one as described previously) are of no real concern as these are taken care of. The business in question is concerned about its processes and higher level languages cater for this.

Hope this clarifies things abit.

osmethod

kenmc

damnyanks wrote:

I would never consider programming a art. Its a trade... at least learning how to do it. To do it correctly is a different story.

Interesting.... why a trade? you mean like a plumber/electrician/plasterer/bricklayer???
If that's the sort of trade you're likening it to then I don't really understand the link - tradesmen don't do any of the design work involved with whatever they're building - they're just told to build a wall here, plaster it, put sockets here there and everywhere.....
Whereas in programming/SW engineering it's all about design - least the stuff I do is....
like the architect designs the house, the programmer/SW engineer designs the system....
Still reckon it's an art to be honest......

rsynnott

Think of C as a form of portable assembly language.

*hugs C*

If you want a small, efficient, crossplatform program with minimal dependencies, C is still a good way to go. You can integrate it with Java, or most other things, if you feel like it (Eclipse is one of the more horrifying examples of this).

rsynnott

damnyanks wrote:

I would never consider programming a art. Its a trade... at least learning how to do it. To do it correctly is a different story.

Wuh? Any idiot can bang together code to do a given thing. The art is in writing code to do that thing well, in a reliable and maintainable fashion.

leeroybrown

C does seem to be the predominately used first year teaching language in the colleges. I think the main reason for this is historical. C has been taught like this for years now going back long before the other options that people would think of (C#, Java, etc) even existed. Universities in general tend to change slowly when it's not pushed. C is still a very useful language to have and most of the other languages taught in later years tend to have C-like syntax.

I studied C in college and found it a very useful way to learn a lot about programming. That said, many people who had less of an aptitude for programming found it difficult.

Hobbes

kenmc wrote:

I would argue that an OO language is not the best one to start off on, because if you become accustomed to OO methodology you would potentially find it quite difficult to go "back" a step to something which didn't handle OO eg C.

And I disagree. OO is partly a language type but it is also a programming mehodology. Something a programmer has to learn if they are to write maintainable code. C doesn't offer the maintainability of OO languages.

There is no one language that can be called "better" than the others

Again you are incorrect. Certain languages were designed for teaching programming and not coding for production itself. For example PASCAL and LOGO.

i.e. a master C programmer would be more than capable of churning out a more stable, secure program faster than a relative newbie in Java or C++ or whatever

And a master Java/C++ programmer can be more capable of churning out a more stable, secure program faster then a relative newbie in C. I don't get your point.

In my opinion programming is an art more so than a science,

It can very much be both. UML, Patterns, Unit Testing, Documenting are all more to do with the science then an artform.

The days of the solo programmer are more or less over. Because of this it is better to learn how to write code to put other people on or that 5-10 years down the line can have modules upgraded/changed without destroying the underlying code. C doesn't easily offer that at the start that an OO would.

(again related to who and what rather than what, hence why it's so difficult to say how long a module will take to write - depends on the writer)

While only partly true the writing of such a document isn't. We rountinely use costing documents with UML diagrams to write out the layout of the code along with times for each part of the module. Generally a costing document (for us) has to be broken up into 5 days or less steps. Anything over 5 days has to be broken up into its subparts. Any professional coder who can't do this or starts writing the code first is writing piss poor code.

Once someone has an understanding of programming and the thought process behind it, then they can start to worry about how to write secure code.

Writing Secure, maintainable code. As I said, C doesn't offer that as easy as other languages.

damnyanks

kenmc wrote:

Interesting.... why a trade? you mean like a plumber/electrician/plasterer/bricklayer???
If that's the sort of trade you're likening it to then I don't really understand the link - tradesmen don't do any of the design work involved with whatever they're building - they're just told to build a wall here, plaster it, put sockets here there and everywhere.....
Whereas in programming/SW engineering it's all about design - least the stuff I do is....
like the architect designs the house, the programmer/SW engineer designs the system....
Still reckon it's an art to be honest......

The design stage can be seen as a artistic action. But the programming like a trade. How many developers around the world are just given a design document and told to make it.

I have no problem with someone considering an art. But a normal tradesman can think their work a art form as well... I think that is more along the lines of having pride in what you do. I love nothing more then having something work correctly that I have created from scratch.

You see the system , program, hello world grow from nothing. It is a difference of opinions I guess. Software is now at the stage where it is everywhere, where it affects peoples lifes and in some cases can be responsible for people being injured if not worse (Weapons systems, software crashes yada yada yada )

damnyanks

rsynnott wrote:

Wuh? Any idiot can bang together code to do a given thing. The art is in writing code to do that thing well, in a reliable and maintainable fashion.

What happens when model based development finally kicks in. They've been saying it for years so lord knows when it will happen. But back in the day people probably scoffed at the idea of writing C to create assembly code.

Like I somewhat stated above. Software is now such a huge part of life that artistic expression on code will probably become a thing of the past. The IEEE and other bodies (SEI) are making a move to create software engineering into true engineering discipline to eliminate errorrs in development (code re-use and general standards) and make it as rapid as possible.

Ok... I do know that I am making little sense at the moment. I will edit the post later or reply. A book on softare engineering is always a interesting read(At least for me ). Its amazing to see screw up's that happened when people tried to create their visions.

But its the 18th... I'm Irish and I live abroad so I went a bit too Patrick yesterday. After some sleep I will make it readable

kenmc

damnyanks wrote:

Like I somewhat stated above. Software is now such a huge part of life that artistic expression on code will probably become a thing of the past. The IEEE and other bodies (SEI) are making a move to create software engineering into true engineering discipline to eliminate errorrs in development (code re-use and general standards) and make it as rapid as possible.

Ah see thats where I think they're barking up the wrong tree. In civil engineering it's all quite easy to do something like this - eg to pour a foundation wall of x*y*z will take x*y*z cubic units of concrete and will require function(y*z) hours to harden. When it's done it's done. This can be easily scaled to a whole building, as you're working with tangible entities - a brickie can lay X blocks an hour and hence can build a wall of a*b in a defined number of hour (assuming he has a supply of raw materials and doesn't take too long over lunch).

In software though, there is nothing tangible. How long will it take to write a tuner driver for the LSI L64733 chip? Well thats just like asking how long a piece of string is. Sure you can break it down into chunks and "day sized" work blocks, but there are SOOOOO many variables.... how good is the chipspec? Has the programmer ever done a tuner driver before? What OS is it running on? What middleware will it use? Then there's all sorts of things like timing, signal degradition etc etc.

Estimation of the amount of work involved in a particular task is one of the biggest problems facing development teams. Especially when trying to debug a problem that happens eg once every 2 days. How can you estimate how long it will take to do this? This is part of where the "art" comes in. Different programmers can debug things in different/cleverer/faster ways than others. And so many things can seemingly affect timing issues, and yet the answer can be something so completely different....

Ok probably too much info but a recent example I had was an audio glitch was appearing every so often in a system I was developing. It seemed to indicate a memory leak was happening, especially as when I added some dummy variables into a structure to push it down the stack a bit, the glitch went away. after a hell of a lot of head scratching the problem turned out to be nothing at all to do with memory.... the dynamic declaration of the extra variables simply slowed the processor *just* enough that a write to the audio chip which happened earlier had enough time to be accepted by the chip before the next write went to the audio chip, so that the 2 writes were correctly handled, and no glitch occurred. How the hell can you account for this sort of thing in "science" where everything has a defined behaviour. How can you account for an unknown bug in a chip which says that register X is not cleared on a soft reset, but turns out that it really is?? The above problem had already been examined by 2 other programmers without success. I got lucky. I tried something they didn't. Dunno how or why I decided to do so, but I did, and it turned out to be the right answer. I'm not saying that I was better than the other 2, I just thought up something different. This sort of bug happens all the time in real world systems, and in this case it was not likely to cause anyone to die, but it would seriously pi$$ someone off it they were watching tv and the audio started acting up every random interval.

Ok I think I've probably gone off on a tangent here so I'm sorry, but I just wanted to stress the points floating through my mind.

As for "standards" then I'm all for it - every project we work on has a coding standard which must be followed, eg stuff like you can't use strcpy, only strncpy to (hopefully) prevent buffer overflows - but even then there's no guarantee that the programmer will not allow the buffer to get written with more data than it can store - but hopefully it should. As for estimation well I would dearly love for there to be a better way of estimating work, to stop the inevitable late nights and weekends that come with the job!!!

In my experience Code Reuse is generally not feasible. Different customers won't allow you to use their code for others, unsurprisingly. Going from one OS to another means that large changes are needed. Different middleware - again a change.Different processors/chips handle things differently, some don't have any floating point numbers. Different amounts of memory/flash. I think there are just too many different variables in the system, and the field is too new. We've been building structures for thousands of years, we've been programming for what - 40?? We've a hell of a long way to go yet.

Anyway, how this as gone from "Why C" to "Is programming an art or a science" eludes me but I think it's all my fault. Now back to work for me. I've a problem to debug But before I go.....

"Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. "(Charles M Strauss)

Hobbes

kenmc wrote:

In software though, there is nothing tangible. How long will it take to write a tuner driver for the LSI L64733 chip? Well thats just like asking how long a piece of string is. Sure you can break it down into chunks and "day sized" work blocks, but there are SOOOOO many variables.... how good is the chipspec? Has the programmer ever done a tuner driver before? What OS is it running on? What middleware will it use? Then there's all sorts of things like timing, signal degradition etc etc.

They are all part of your costing document. A (proper) costing document doesn't fit within a set time but lists off all the knowns, possible unknowns and critical parts that need to be overcome. Other parts of what you listed off would be put into the functional spec.


A bad costing document from managements point of view is where the developer is given X days to get all features in. A bad costing document based on developers point of view is when they are incapable of breaking down the total time required to do something or give silly totals that are not realistic.

Estimation of the amount of work involved in a particular task is one of the biggest problems facing development teams. Especially when trying to debug a problem that happens eg once every 2 days. How can you estimate how long it will take to do this?

You cost for a set time for fixing SPR's if you have an SPR that is taking more hours you either adjust the time (project or more developers) or pend the SPR for next release while your developers work on other SPRs.

This is part of where the "art" comes in. Different programmers can debug things in different/cleverer/faster ways than others.

There is no art involved. So one developer finds a faster way, then they should document that system for other developers to follow. Any developer that doesn't do this is detrimental to the project.

*snip* How the hell can you account for this sort of thing in "science" where everything has a defined behaviour.

Unit testing.

The above problem had already been examined by 2 other programmers without success. I got lucky. I tried something they didn't. Dunno how or why I decided to do so, but I did, and it turned out to be the right answer. I'm not saying that I was better than the other 2, I just thought up something different.

Again you share this knowledge with the other developers. Document it and move on. You also write a unit test to check for this in the event it shows up again.

Fixing *unknowns* can be an artform but it doesn't mean that writing software is.

As for estimation well I would dearly love for there to be a better way of estimating work, to stop the inevitable late nights and weekends that come with the job!!!

If you are working silly hours it means that your project is poorly planned.

I think there are just too many different variables in the system, and the field is too new.

The field isn't that new at all. There are many kinds of patterns and processes for dealing with certain fields of computing. IEEE are a good resource on this.

I also recommend reading Rapid Development.

Tobias Greeshman

To the OP, I think that the only reason to use teach students C in an Electronics course, would be regards to showing how hardware is controlled by software. As C can be used in a very low level and used with inline assembly, makes it a prime choice for using it in such a course.

RicardoSmith

As in all walks of life, theres a lot of things that make someone good at what they do. Some of them would be good training, good work practise, and a talent (natural or learnt) for what they are doing. A programming language is a tool do job. You pick the right tool for the job.

Zombrex

breadmonkey wrote:

I'm in 1st Engeineering and we've been doing some programming in C. Is there any reason to choose this language?

Thanks

Is the most reasonable answer that most modern widely used languages (C++, Java, C#) are based on C syntax and because C is a good example of a structured programming language, useful to learn before you get into more complex ideas such as OOP, AOP or COP.

Plus C is a good middle ground between the structure of high level programs and the way they act when compiled down to machine code, so it is a good language if you are trying to grasp how programs do things rather than just what they do.

rsynnott

Of course, most systems programming is still done in C, and it's popular as well in the embedded field.