 Tim Bray: Language fermentation
started 5/9/2003; 1:58:51 PM - last post 5/11/2003; 3:52:38 PM
|
|
Ehud Lamm - Tim Bray: Language fermentation 
5/9/2003; 1:58:51 PM (reads: 1926, responses: 7)
|
|
| Tim Bray: Language fermentation |
|
maybe everything we thought we knew about strong typing is wrong. Herewith a bit of surveyware with a touch of debunking and a practical footnote on Java exception handling.
Nice piece.
We may not agree with the type-luddites but we should keep our ears to the ground lest we find ourselves run over.
Posted to general by Ehud Lamm on 5/9/03; 2:00:18 PM
|
|
|
|
Ehud Lamm - Re: Tim Bray: Language fermentation
5/9/2003; 2:09:46 PM (reads: 904, responses: 0)
|
|
|
Type-luddites, n. Those that think that instead of more expressive type systems we need weaker and less expressive type systems.
|
|
Patrick Logan - Re: Tim Bray: Language fermentation
5/9/2003; 5:02:27 PM (reads: 876, responses: 0)
|
|
|
I vow to stay out of this one. Read-only mode is on.
No how many inaccuracies I see. 8^)
|
|
Chris Rathman - Re: Tim Bray: Language fermentation
5/9/2003; 5:23:58 PM (reads: 862, responses: 0)
|
|
|
Well, for those that are advocating testing, I'd like to see something a little more formal - i.e. built into the programming language - to support the concept of testing. Unit tests are fine as an idiom, but they really amount to an additional level of complexity in any software that you write - requiring a parallel set of software for every bit software written.
Other than Eiffel's Design-by-Contract, are there other formal mechanism to ease the concept of testing within software (and no, assertions don't count as they are too low level). Testing as defined by most seems to amount to giving up on solving the problem via language design, and fallback of software engineering best practices.
P.S., there's a conversation on one of my other hangouts that talks about an article from Cringely and gets into some specifics about testing. Not really of interest from a Programming Language standpoint, but might be of interest to those looking at the practical issues involved in unit testing.
|
|
Kimberley Burchett - Re: Tim Bray: Language fermentation
5/10/2003; 5:40:26 PM (reads: 719, responses: 1)
|
|
|
On the subject of having testing built into the language, I recently wrote up a little blurb about my experience with QuickCheck (previously mentioned on LtU). I think it comes pretty close to having testing built into the language. To use it, you basically write some invariants, and it tests them with random data. I find that the automatic generation of random inputs makes using QuickCheck feel very different from doing unit testing. It feels more like pushing the type checker into the realm of runtime values. I think this is because it's based on proving that an invariant holds for all possible inputs, instead of checking particular code paths. (Of course the "proof" is only falsifiable, never verifiable, but it still feels like it's proving the invariants). It's like Eiffel's DBC, but with a more exhaustive sample set (as far as I know, DBC is not verified statically, and is only checked for the code paths that actually get executed in the program -- therefore leaving the burden of writing test drivers up to the programmer).
It seems like this kind of testing could easily be integrated into any programming language that has reflection and static typing (otherwise it could be difficult to generate random inputs automatically). Or you could work around the lack of static typing by specifying "data generators" for each test -- the only drawback being that with something as lightweight as QuickCheck, every extra line of code increases the mental burden substantially. So if it took, say, two lines of code to define the generator to use for a test, that would triple the "weight" of the tool.
|
|
andrew cooke - Re: Tim Bray: Language fermentation
5/11/2003; 10:22:46 AM (reads: 683, responses: 0)
|
|
|
Random checks must be very efficient, though. After all, it's normally "obvious" what values are likely to break code (0, 1, null, etc).
|
|
Paul Snively - Re: Tim Bray: Language fermentation
5/11/2003; 10:35:01 AM (reads: 624, responses: 0)
|
|
|
I'm also disappointed that I've not yet seen any discussion of the various languages that blur the distinction between "strong" and "weak" typing, e.g. the majority of functional languages, which are strongly typed but which employ type inference so that the programmer only must declare types where there are ambiguities detected by the inferencer. It's possible to have your cake and eat all but a few crumbs, too.
|
|
Isaac Gouy - Re: Tim Bray: Language fermentation
5/11/2003; 3:52:38 PM (reads: 598, responses: 0)
|
|
languages that blur the distinction between "strong" and "weak" typing
None of the languages I've used since Smalltalk have been fun!
Except for Clean.
There's a good deal of childish pleasure in looking at the types the system has figured out all by itself. And of course, a good deal of work-a-day delight that I didn't have to explicitly define the type of every function ;-)
Clean does more than type inference to blur this distinction:
In CLEAN 2.0 we have added a dynamic type system such that CLEAN now offers a hybrid type system with both static as well as dynamic typing. An object (expression) of static type can be packed into an object of dynamic type (a "Dynamic") and backwards. The type of a Dynamic can only be checked at run-time.
There are many papers available.
|
|
|
|