A
adgaur.niit
Developed by Denis richi.............
Developed by Denis richi.............
Jujitsu Lizard said:If you can't consistently write correct code, you SHOULD be using another
language.
Which self correcting language would you recommend?Jujitsu said:If you can't consistently write correct code, you SHOULD be using another
language.
Jujitsu said:If you can't consistently write correct code, you SHOULD be using another
language.
Richard said:August Karlstrom said:
Since anyone who can't consistently write correct code should not be
using /any/ programming language, we can draw the further
conclusion that nobody should be programming *at all*. Whilst I
don't actually agree with this rather extreme position, it would
certainly be tempting to use Sturgeon's Law to sack 90% of the
programmers out there, and then sit back and wait for the fabulous
stuff that the remaining 10% will eventually produce.
In C you can do marvelous things like:
a)Continuing to use a block of memory after it has been deallocated.
b)Returning a pointer to an automatic variable, which is then used after the
stack frame has expired.
c)Allowing an integer array index to roll over backwards, setting up to
corrupt (for example), unrelated memory or the stack frame.
Which self correcting language would you recommend?
That would be Dennis Ritchie:
http://en.wikipedia.org/wiki/Dennis_Ritchie
C in my opinion is "just right".
The reason is that if you go too high-level, there are performance
implications.
C is, plus or minus a little, a structured assembler.
C gives you enough rope to hang yourself (no array bounds checking, etc.),
but on the other hand you can write those things yourself if you so desire
and you really won't take a performance hit over a "high-level" lanugage, as
your compiled code will do about the same things that the compiled
"high-level" language would do.
If you can't consistently write correct code, you SHOULD be using another
language.
I'm a big fan of C + datastructure tools. I find C + datadraw to be
higher performance than C alone, while more productive for EDA
applications than C++. [...]
There's a reason most new EDA applications are still written in C, and
it's not that programmers are stupid.
Let's start by making sure that we have the same definition of "consistent".
From dictionary.com:
Reliable; steady: demonstrated a consistent ability to impress the critics.
I don't think consistency as it is commonly used requires 100% success. I
think 80% might be enough.
If I write 1000 lines of code and 2 are wrong ... that meets my definition.
user923005 said:[...]
If you can't consistently write correct code, you SHOULD be using another
language.Do you know anyone who *can* consistently write correct code?
I certainly can't; I make mistakes.
Let's start by making sure that we have the same definition of "consistent".
From dictionary.com:
Reliable; steady: demonstrated a consistent ability to impress the critics.
I don't think consistency as it is commonly used requires 100% success. �I
think 80% might be enough.
If I write 1000 lines of code and 2 are wrong ... that meets my definition.
Consistent makes no sense in this context. ...
... If 100% of the lines of
code are bad each and every time, then the code is consistent. If 50%
of the code is bad each and every time, then the code is consistent.
If 0% of the code is bad each and every time then the code is
consistent.
user923005 said:[...]
If you can't consistently write correct code, you SHOULD be using another
language.
Do you know anyone who *can* consistently write correct code?
I certainly can't; I make mistakes.
Let's start by making sure that we have the same definition of "consistent".
From dictionary.com:
Reliable; steady: demonstrated a consistent ability to impress the critics.
I don't think consistency as it is commonly used requires 100% success. I
think 80% might be enough.
If I write 1000 lines of code and 2 are wrong ... that meets my definition.Consistent makes no sense in this context. ...
That's an ironic comment to make, given that the following discussion
completely ignores the context:
... If 100% of the lines of
code are bad each and every time, then the code is consistent. If 50%
of the code is bad each and every time, then the code is consistent.
If 0% of the code is bad each and every time then the code is
consistent.
In itself, that's correct. However, the context resolves all of the
uncertainty that you've introduced by ignoring the context. The
discussion wasn't about "consistent code". The context of this
subthread is the phrase "can't consistently write correct code", and
those few extra words rules out the possibility the phrase refers to
code that is consistently bad.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.