A little of coordination for Rosettacode
bearophile
bearophileHUGS at lycos.com
Sat Feb 16 10:48:53 PST 2013
Jos van Uden:
> I added that precondition reluctantly, that's why its short
> :-). I really feel that
> input validation should be done elsewhere.
A full validation needs to be done somewhere :-)
> I was thinking about adding a factory method to the UTM that
> accepts a string array,
> parses and validates it, and returns a fully initialized
> immutable TuringMachine.
> It would still be a lot of ugly code though.
Probably in D there are better solutions.
> That stronger typing can reduce the need for input checking is
> something I find interesting.
It's interesting :-) A strong typing has some disadvantages (the
code is more fussy, the program usually gets a little less easy
to read and a little longer, etc.), but it has some advantages
too. Languages like Ada, Haskell and ATS enjoy such strong typing
to avoid many bugs and many run-time errors.
In some Rosettacode Tasks I have put two different solutions, one
less and one more strongly typed:
http://rosettacode.org/wiki/Hidato#D
http://rosettacode.org/wiki/Matrix_multiplication#D
There are languages like ATS (http://www.ats-lang.org/ ) able to
catch statically many problems otherwise found at run-time in
lesser languages. Well written ATS programs are also fast as C
programs, so there is no loss in performance. On the other hand
writing ATS code is not easy.
> I'll have a look at the Ada code.
Ada code is very readable (far more than C++). But compared to D
you have to write too much code.
>> (but we have also to benchmark if this doesn't decrease the
>> program performance for a
>> successive bigger Busy Beaver machine):
>
> On the other hand, if we have stronger typing we may not have
> to do the rather expensive
> checks that are currently in the loop.
Right :-)
Onward to the next Rosetta tasks :-)
Bye,
bearophile
More information about the Digitalmars-d-learn
mailing list