After a long delay, I have finally released a first version of a tutorial for easyVision. I know that this system is only useful to me, but trying to explain something to other people is the best way to find things that can be improved, have a poor design, or more probably, that I don't really understand.
For instance, I noticed that the definition of camera combinators was too verbose. We can now write more elegant programs like this:
main = run $ camera >>= observe ~~> f . g . h >>= zoom
In Haskell, if a program compiles it is very likely correct. Also, ugly code strongly suggests that the essential problem is not well understood. Trying to write a better solution we often discover that it can be reformulated in a more general way. And this opens up still more possibilities for improvement.
6 comments:
I know that this system is only useful to me
I have long wanted to try playing with it -- just need to find some time.
Thanks! I hope you enjoy it.
FYI, the "tutorial" link is broken.
Thanks TomMD, I have fixed the link.
"In Haskell, if a program compiles it is very likely correct."
I definitely want proofs, or expect rephrasing here!
The fact that it compiles only says that you won't get type errors, but that's all! About correctness of the program, about the fact that it does what you want it to do, successful compilitation doesn't say much.
I reckon there is *much more* haskell programs with bugs than programs without. Would you call a program that does not behave as expected "correct"?
Cheers
Axio: Successful compilation in a pure functional language with a strong type system says a lot of things!
Why Haskell just works
Why functional programming matters
Post a Comment