The strong vs weak typing issue is very vague and either side could be defended for nearly every programming language as you can see from this very discussion. See http://en.wikipedia.org/wiki/Strongly-typed_programming_language for more examples. In the grand scheme of things, weak vs strong has very little to do with the suitability of a language for a design pattern or algorithm.

I'm proposing that we use encapsulation and possibly ADTs to define clear boundaries for functionality in the code base. Rather than have one massive code base, I'd like to see subsystems that can be worked on internally with minimal effect to the users of that subsystem. OpenOCD has some of that and Zach has been doing a lot of work to refine that.

--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split it with him."
 -- Unsigned



On Jun 9, 2009, at 8:51 PM, David Brownell wrote:

On Tuesday 09 June 2009, Rick Altherr wrote:
                although this is the first time I've ever
heard anyone apply that term to C.  ...

I've commonly heard C and C++ referred to as strongly-typed.

Never *once* have I heard that usage before yours.  Usually C gets
described as a weakly/loosely typed language.  (This is in the
context of multiple classes and seminars that did comparative
studies of dozens of programming languages and type systems.)


The fact
that you can't declare a variable without a type is an indication of
this.

No; it just means they have types, and require declarations.

But in fact, C doesn't require, and never has required, types
for everything.  I just compiled the following; no errors, and
not even any warnings unless I specify "-std=c99".

   main(argc, argv)
   {
        argc = argv;
        return 0;
   }

Over time, C has integrated mechanisms that lets one's code
trigger warnings from some flavors of type abuse.  But at
its core, it's still weakly typed.

Plus, having a declaration says nothing about whether that
will be "strongly" enforced, or can instead be suborned.


void * let's you work around some undesirable effects of strong-
typing, but it is a type itself.

That "work around" means "violate any type rules you want",
which is prima facie evidence that the type system is not
what's called "strong" ... either at compile time, or at
run time.

Contrast that to something like LISP or Lua ... or even TCL.
In key ways, those have stronger typing than C:  they have
only a handful of data types and you can't escape them.
(That property is also a flavor of what's called "safety",
and one which lends itself to crash-free software.  C is
not known for being crash-free; neither is C++.)

But on the flip side their type systems are not extensible,
so when you build abstraction layers you've got to define
your own typing conventions.   Which can't be enforced at
compile time (another aspect of "safety", which would help
some other robustness characteristics), so they're weak in
those respects.  Yet C provides some extension mechanisms...

:)



However, I'm all in favor of evolving code to respect clearly defined
data types, which encapsulate roles and responsibilities to support
better system structures. If there's a better way to do it, I've not
yet come across that answer.  :)

That's really all I'm recommending. I've seen a dynamic- and strongly-
typed language do very well for doing encapsulation and using ADTs to
make a very clean system architecture that allows for lots of future
extensions.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to