On 17 Aug 2006, [EMAIL PROTECTED] wrote: On 2006-08-17, Ted Zlatanov <[EMAIL PROTECTED]> wrote: > On 17 Aug 2006, [EMAIL PROTECTED] wrote: > > On 2006-08-17, Ted Zlatanov <[EMAIL PROTECTED]> wrote: >>>> You could consider Perl. >>> >>> If I wanted a strongly timebomb-typed language, I'd probably use Lua. >>> But I don't think timebomb typing should be used for largeish projects, >>> especially not ones that one should be able to depend on, although >>> strong timebomb typing can be quite nice for small hacky stuff. >> >> I think the term "timebomb" reveals a lot of bias. But that, of >> course, is your prerogative. I'll just point out that Perl modules >> hide complexity and can enforce strong types, if that's what you >> need. > > 'Timebomb' refers to errors related to typing being possible at run > time, be this either runtime type errors in strong timebomb typing, > or NULL pointer references in weak timebomb typing.
Maybe this is a term I haven't heard before. I have always heard of weakly- and strongly-typed languages. It seems to me biased regardless, as it infers a "bomb" effect from weak types. Sorry I assumed it was your own term. > Or are you telling me that perl has type inference (it surely > doesn't have type signatures), and can at compile time assure me of > the type-correctness of the program, instead of having me and the > users wait for the moment, when the program crashes in such an > error? Perl enforces types at run time. But it doesn't really enforce them in the classic sense - it's very accomodating. There are Perl modules and pragmas that will build and enforce types for you. Class::Meta::Type for instance. But it's just not an issue, usually. In my years of Perl usage, I have had very few problems due to types. A Perl program will not crash because of the wrong type. It will crash because the interpreter couldn't find a method, usually (or other fatal errors such as division by zero or trying to invoke a method on an undefined value). You can use eval() to wrap sections of the program to protect against such issues, or test your inputs. I recognize that this requires a different mode of thinking, and do not wish to force it upon you. My original note was just a suggestion. Ted
