[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inline VALOF


Perhaps we should be selective in applying Occam's razor - there are many things that are more 'complex' than they need to be but that 'complexity' introduces convenience which is of more value.

- Differential calculus - we COULD stick with "the limit as x tends to zero"
- High-level programming languages - we COULD do it all with assembler
- occam (see above)

A real challenge is that each user probably has their own view of what is convenient - I certainly do and different projects demand different conveniences. A programming language that is easy to use for data-base access is unlikely to be the best for scientific calculations and neither very good for an embedded processor in a photocopier. There is never likely to be agreement that "Language X" is the best for everything and hence the observed lack of universal acclaim for occam, C, Java, FORTRAN, ... (although occam's razor would suggest it could all be done with 80x86 code). It is likely that the minimal offering suggested by Occam's razor may be 'elegant' but probably considered of little practical use. This is the thinking behind my thinking-aloud on the subject of identifying the application that would see occam(-like) notation as valuable. (Summary of responses: where there is a powerful need for security or correctness guarantees.)

[Before anyone denies wanting their own notation I would point out that declaring a procedure to encapsulate things and give them a useful abbreviation IS adding to a language (in an application specific way) and clearly shows the desire, and value, of moving beyond the minimalist approach.]

   Barry (awaiting counter-arguments).

Dr Barry M. Cook, BSc, PhD, CEng, MBCS, CITP, MIEEE
4Links Limited,
The Mansion,
Bletchley Park,
MK3 6ZP,
----- Original Message ----- From: "A.E.Lawrence" <A.E.Lawrence@xxxxxxxxxxx>
To: "Denis A Nicole" <dan@xxxxxxxxxxxxxxx>
Cc: <occam-com@xxxxxxxxxx>
Sent: Wednesday, December 13, 2006 1:02 PM
Subject: Re: Inline VALOF

Denis A Nicole wrote:
On Tue, 12 Dec 2006, Adam Sampson wrote:

Has anybody:

- used inline VALOF in real code at all?

- found interesting uses for inline VALOF (that can't be obtained as
 elegantly using named FUNCTIONs)?

Won't taking VALOF out upset the BCPL community? I think we once supported
mixed occam1/BCPL on the Atari ST and maybe the Sinclair QL.

More seriously, could occam-pi support something like the B ? E : E'
syntax of C and Java or the E if B else E' of Python 2.5? It might be an
appropriate replacement.

Would this not violate the "razor"? Quite apart from my instinctive
repugnance :-)