Better numbering in intro + better conclusion

This commit is contained in:
Yann Esposito 2012-06-14 17:21:32 +02:00
parent 8527baa019
commit 79409a8a72
2 changed files with 17 additions and 11 deletions

View file

@ -47,5 +47,5 @@ And here are the intermediate steps:
blogimage("HGL_Plan.png","The parts of the article")
From 1 to 3 it will be _dirtier_ and _dirtier_.
We start cleaning everything at the 4th part.
From the 2nd section to the 4th it will be _dirtier_ and _dirtier_.
We start cleaning everything at the 5th section.

View file

@ -1,19 +1,25 @@
## Conclusion
In conclusion, if you add the courage to read this long article,
you should see how to organize your code in a functional way.
As we can use imperative style in a functional language,
know you can use functional style in imperative languages.
This article exposed a way to organize some code in a functional way.
I'd like to stress the usage of Haskell made it very simple to achieve this.
The usage of Haskell made it very simple to use our own data type.
The gigantic advantage is to code while being perfectly pure.
Once you are used to pure functional style,
it is hard not to see all advantages it offers.
In the two last sections, the code is completely pure and functional.
The code in the two last sections is completely pure and functional.
Furthermore I don't use `GLfloat`, `Color3` or any other OpenGL type.
Therefore, if tomorrow I want to use another library I could do this simply by updating the `YGL` module.
If I want to use another library in the future,
I would be able to keep all the pure code and simply update the YGL module.
The `YGL` module is a "wrapper".
The `YGL` module can be seen as a "wrapper" around 3D display and user interaction.
It is a clean separator between the imperative paradigm and functional paradigm.
Furthermore I demonstrated you can make user interaction and display 3D objects in real time using only a pure functional paradigm.
If you want to go further, it shouldn't be hard to add parallelism.
This should be easy mainly because most of the visible code is pure.
Such an optimization would have been harder by using directly the OpenGL library.
You should also want to make a more precise object. Because, the Mandelbulb is
clearly not convex. But a precise rendering might be very long from
\\(O(n^2log n)\\) to \\(O(n^3)\\).