Re: Just starting off in obj C
Re: Just starting off in obj C
- Subject: Re: Just starting off in obj C
- From: Ian Joyner <email@hidden>
- Date: Mon, 27 Oct 2008 18:08:25 +1100
On 27/10/2008, at 4:37 AM, j o a r wrote:
On Oct 25, 2008, at 11:45 PM, Ian Joyner wrote:
Sure -- the C runtime is brittle in the ways you mentioned and
thank goodness tools like the Clang static analyzer and Valgrind
are providing means of finding and eliminating such bugs.
Of course, retro-fitting static analysers to inherently unsafe
languages, can only go so far. Static analysis has its limits.
I agree. I have never liked tools like lint. A well-defined
language with well-implemented compilers should not need after-the-
fact hacks.
I wouldn't call them hacks.
You're probably right, I've been far too anthropomorphic in my
language with terms like lazy and brittle, although this makes a
point. A piece of software can't be lazy, it just executes whatever
the programmer has specified, so it is actually the programmer that is
lazy, or as in the case of C, when compilers were first written, they
were on very limited machines, so the software design was very
constrained by this fact. Same comment goes for bugs, as if they are
something that has crawled into the software.
For the most part they're not providing functionality missing from
the compiler, they're complementing the compiler with functionality
that doesn't belong in the compiler. The compiler should concern
itself with the language specification, not custom conventions like:
* Parameters passed to format strings
* Memory management characteristics of objects returned from
functions (retain/autorelease)
* If you called super or not in dealloc
I agree, but on a case-by-case basis. There are some problems that can
be avoided altogether because the language is well designed. Then
there are errors that can and should be caught by the compiler. (I
don't like languages where compilers give a whole lot of warnings.)
Then there are probably legitimate cases.
These are all framework / library specific rules. This is one of the
areas where Clang shines. That said, perhaps compilers should be
extensible to allow for custom rules and whole program analysis? Not
sure if integrating the two would bring any significant advantages,
besides perhaps convenience, though?
Well, I'll choose convenience, why make programming – a fundamentally
difficult task – more difficult than it needs be.
Compilers also work at, well, compile time, and there are a number
of problems that you just can't (!) catch at compile time no matter
what general purpose imperative language that you choose. This is
where unit tests and other runtime checkers, such as Valgrind, comes
into play.
Well, the need for testing should be kept to a minimum. It has become
too prominent lately with TDD. Of course, testing will always be
needed, but dependence on testing should be minimized. In fact, that
is so important it is a Deming principle "Cease dependence on
testing". That there will always be problems that you can't catch
until run time does not mean that you should not catch the problems
you can detect by means of static analysis.
Tools such as lint, and the other tools you mention would be even more
powerful if they did not need to catch a whole bunch of avoidable
trivialities.
Ian _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden