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