chip@tct.uucp (Chip Salzenberg) (03/28/91)
According to rick@cua.cary.ibm.com.UUCP (Rick DeNatale): >I'm actually a little bit surprised that people put so much faith in compile >time type checking systems that they are willing to accept an implementation >that allows type errors that escape the compiler to cause wild branches and >other unsavory acts ... Please note! The C++ type system does, in fact, prevent such type errors -- UNLESS the programmer lies to the compiler about the type of an object. Such lies are entirely the programmers fault, and do not reflect badly on the language. >I haven't seen a strong typing system yet that doesn't require you to >(hopefully carefully) circumvent it at times ... And I, in turn, have never seen an automobile in which it is not necessary to take off the seatbelt occasionally, even when driving. That doesn't mean that seatbelts are counterproductive. We've all heard the stories of people who drowned in their submerged cars because they couldn't unfasten their seatbelts. But such anecdotes leave unmentioned the thousands of lives that are lost in mundane accidents, lives that could have been saved if only seatbelts were used. Arguments against static typing are often based on similar anecdotal evidence; such arguments are similarly bogus. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
carroll@cis.udel.edu (Mark Carroll) (03/29/91)
In article <27F11D7B.6309@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to rick@cua.cary.ibm.com.UUCP (Rick DeNatale): >>I'm actually a little bit surprised that people put so much faith in compile >>time type checking systems that they are willing to accept an implementation >>that allows type errors that escape the compiler to cause wild branches and >>other unsavory acts ... > >Please note! The C++ type system does, in fact, prevent such type >errors -- UNLESS the programmer lies to the compiler about the type of >an object. Such lies are entirely the programmers fault, and do not >reflect badly on the language. > But C++ has it's share of semantic ugliness. Consider the (now) well known problems of copy constructors. Or the fact that it requires you to use multiple inheritance in order to kludge a simulation of dynamic typing. (Sorry, I'm one of the folks who still don't believe in multiple inheritance. I've never been able to see any case in which multiple inheritance was a really good solution - except where it as basically just a kludge around a static typing system.) >>I haven't seen a strong typing system yet that doesn't require you to >>(hopefully carefully) circumvent it at times ... > >And I, in turn, have never seen an automobile in which it is not >necessary to take off the seatbelt occasionally, even when driving. >That doesn't mean that seatbelts are counterproductive. > >We've all heard the stories of people who drowned in their submerged >cars because they couldn't unfasten their seatbelts. But such >anecdotes leave unmentioned the thousands of lives that are lost in >mundane accidents, lives that could have been saved if only seatbelts >were used. Arguments against static typing are often based on similar >anecdotal evidence; such arguments are similarly bogus. A fine example of proof by analogy. And as usual, it doesn't prove anything. Static typing is NOT a seatbelt. Dynamic typing is NOT less safe than static typing. I've said the following several times, but just in case it hasn't sunk in yet: Any typing error that would be trapped in a staticly typed language can be captured in a dynamically typed languages using dataflow analysis. If the error can't be caught with dataflow, then either the program would be written differently in the static language (in which case, the same safe version could be written with the dynamic typed language), or the staticly typed language would have a kludged dynamic typer, in which case the static language would be as subject to error as the dynamic. >Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> <MC> -- ---------------------- Mark Craig Carroll: <MC> ------------------------ ------ U of Del. Grad Student in CIS ------ EE/CIS LabStaff Hacker ------ -- Resident Wierdo @ 105 E Cleveland Ave, Newark DE - carroll@udel.edu -- ---------------------- Shalom Achshav - Peace NOW! ----------------------
jls@rutabaga.Rational.COM (Jim Showalter) (03/30/91)
>Any typing error that would be trapped in a staticly typed language >can be captured in a dynamically typed languages using dataflow >analysis. But now you need an additional tool besides an editor, compiler, linker, debugger. And what makes you think the programmer will always remember to USE the dataflow analyzer? What if he/she is in a hurry? (Oh, right, programmers NEVER cut corners to meet schedules...) The idea of the "simple language aided and abetted with other tools" has been tried with lint for C, with predictable results. You'll note that there is no need for lint++ with C++, precisely because the C++ compiler does the work instead. This is progress. -- ***** DISCLAIMER: The opinions expressed herein are my own, except in the realm of software engineering, in which case I've borrowed them from incredibly smart people.
carroll@cis.udel.edu (Mark Carroll) (03/30/91)
In article <jls.670284598@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: >>Any typing error that would be trapped in a staticly typed language >>can be captured in a dynamically typed languages using dataflow >>analysis. > >But now you need an additional tool besides an editor, compiler, linker, >debugger. And what makes you think the programmer will always remember >to USE the dataflow analyzer? What if he/she is in a hurry? (Oh, right, >programmers NEVER cut corners to meet schedules...) The idea of the >"simple language aided and abetted with other tools" has been tried >with lint for C, with predictable results. You'll note that there is >no need for lint++ with C++, precisely because the C++ compiler does >the work instead. This is progress. Do people on this group totally lack any knowledge of compilers? Dataflow analysis is a function of the compiler. It's primarily an optimization technique that also happens to have quite a few other uses. A dataflow analyzer would not be a separate tool. Frankly, an optimizing compiler that isn't already doing dataflow is a rather miserable compiler. And the statement "This is progress" applied to C++ seems to be a rather poor joke. There's damned little about C++ that could be called "progress". Honestly, what (besides multiple inheritance) is in C++ that wasn't in Simula? The only difference is that the C++ is even uglier. (Sorry, but I find C++ to be the ugliest, cruftiest, most primitive excuse for an object-oriented language that I can imagine.) <MC> -- ---------------------- Mark Craig Carroll: <MC> ------------------------ ------ U of Del. Grad Student in CIS ------ EE/CIS LabStaff Hacker ------ -- Resident Wierdo @ 105 E Cleveland Ave, Newark DE - carroll@udel.edu -- ---------------------- Shalom Achshav - Peace NOW! ----------------------
johnson@cs.uiuc.EDU (Ralph Johnson) (04/02/91)
In article <49229@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark Carroll) writes: |> |> Any typing error that would be trapped in a staticly typed language |> can be captured in a dynamically typed languages using dataflow |> analysis. If the error can't be caught with dataflow, then either |> the program would be written differently in the static language (in |> which case, the same safe version could be written with the dynamic |> typed language), or the staticly typed language would have a kludged |> dynamic typer, in which case the static language would be as subject |> to error as the dynamic. |> Any proof of this claim? I don't believe it. This claim seems to be the same as saying that dataflow analysis can always determine the types of variables and expressions. This is not true. Given a powerful enough type system, type inference is undecideable. In general, it is easier to decide whether a program is legally typed than to discover a legal typing for it. Determining whether a program will have a typing error often requires finding program invariants. Dynamic typing means that programmers don't have to write down these invariants, which is why languages with dynamic typing are easier to program in, at least for medium-scale programming. For the record, I am a Smalltalk fan, and have been working at developing a type system and a type inference system for it. Type inference is basically the same as dataflow anlysis. Type inference is MUCH harder than type checking. It has lots of advantages, to be sure. However, I don't believe that "any typing error" that would be detected by a type checker could be detected by a type inference system, i.e. by dataflow analysis. Ralph Johnson -- University of Illinois at Urbana-Champaign
chip@tct.com (Chip Salzenberg) (04/02/91)
According to carroll@cis.udel.edu (Mark Carroll): >But C++ has it's share of semantic ugliness. Well, sure. But we're not in a competition, we're discussing specific language features related to typing. Right? >Or the fact that it requires you to use multiple inheritance in order to >kludge a simulation of dynamic typing. (Sorry, I'm one of the folks who >still don't believe in multiple inheritance...) I haven't needed either MI or dynamic typing yet. >Any typing error that would be trapped in a staticly typed language >can be captured in a dynamically typed languages using dataflow >analysis. I continue to consider this statement patently wrong, unless someone has solved the halting problem and didn't tell me. :-) -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
alms@cambridge.apple.com (Andrew L. M. Shalit) (04/03/91)
In article <27F11D7B.6309@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: According to rick@cua.cary.ibm.com.UUCP (Rick DeNatale): >I'm actually a little bit surprised that people put so much faith in compile >time type checking systems that they are willing to accept an implementation >that allows type errors that escape the compiler to cause wild branches and >other unsavory acts ... Please note! The C++ type system does, in fact, prevent such type errors -- UNLESS the programmer lies to the compiler about the type of an object. Such lies are entirely the programmers fault, and do not reflect badly on the language. That's a very good point. If programmers could just get out of the habit of putting bugs in their programs, all kinds of programming tools would become unnecessary. Unfortunately, most programmers seem to want to keep putting bugs in their programs. Maybe they just do it for sentimental reasons, or maybe it's something to do with job security. But I agree with Chip, there's no reason for a programming language or environment to do anything to help such stubborn people! -andrew