Re: [Algorithms] Complexity of new hardware
Brought to you by:
vexxed72
Menu
▾
▴
Re: [Algorithms] Complexity of new hardware
|
From: <ne...@tw...> - 2009-04-26 16:52:14
|
<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><br><br> <blockquote webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size: 10pt; color: black; font-family: verdana;"> <div > -------- Original Message --------<br> Subject: Re: [Algorithms] Complexity of new hardware<br> From: Conor Stokes <bor...@ya...><br></div></blockquote><br><blockquote webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size: 10pt; color: black; font-family: verdana;"><div > Functional programming is a very good tool, but it's too pure a tool for production software. Most production software has areas that are "do this, then do that", which pure functional language still has awkward and heavy abstractions for (i.e. an extra level of thought that isn't necessary for the functionality required). It is also interesting that when Tim Sweeney said in his programming-language-for-the-future talk that the "graphics engine" would be "fuctional", yet he doesn't mention that rendering (as it currently stands) occurs in order and is highly stateful. Graphics hardware requires that you set your states, followed by your rendering commands, in order, which is a highly imperative way to think. This really shows that large problems tend to be made up of mixed solutions, that don't follow any one set of rules.<br><br></div></blockquote><br>Monads do give you a way to do imperative code in functional languages. As a half-way relevant example, I find it easier to program OpenGL using the Haskell bindings that I do using the C/C++ bindings. To turn off blending, then draw a long list of triangles, then a list of quads:<br><br>do blendFunc $= Nothing<br> renderPrimitive Triangles (mapM vertex vs)<br> renderPrimitive Quads (mapM vertex vs2)<br><br>versus something like:<br><br>glDisable(GL_BLEND);<br>glBegin(GL_TRIANGLES);<br>for (int i = 0; i < vs.length();i++) drawVertex(vs[i]);<br>glEnd();<br>glBegin(GL_QUADS);<br> for (int i = 0; i < vs2.length();i++) drawVertex(vs2[i]);<br> glEnd();<br><br>I realise that's some very simplistic code (no display lists and so on), but I think (especially with Haskell under discussion), saying that it cannot do ordered things is misrepresentative, once you understand monads. (I do accept that having to understand monads is a barrier to learning Haskell against, say, C.) In Haskell you can get all the nice little features of functional programming (map and so forth), alongside all the order of imperative programming.<br><br>I think you are right that Haskell has not been used in enough large-scale projects to see if it scales well enough in terms of software development, but it has at least the capability to do all aspects of games. Someone did port the Quake 3 engine to Haskell without any leftover C, for example (<a href="http://haskell.org/haskellwiki/Frag">http://haskell.org/haskellwiki/Frag)</a>.<br><br>Neil.<br><blockquote webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size: 10pt; color: black; font-family: verdana;"> </blockquote></span></body></html> |
