<br>a) you can generate c++ with it :) (but don't tell it.<br>it may be regarded as offense)<br><br>b) - <br><br>c) - <br><br>d) stop debugging, you don't need it that much in<br>haskell. But you need profiler. If they really want<br>
to print something in pure function you can show<br>them function 'trace', from Debug.Trace<br><br>e) I don't think that C++ people think that types are bad.<br>If they do you can tell (beside the types don't let you<br>
mess up to much and stimulate clarity and documentation)<br>about how easy is to do refactoring in typed language. <br><br>f) You can show them Atom [1]. 5k Haskell code generates <br>20k C-code and it all works in real time in real trucks. <br>
Or Copilot. It's going to be used in airplanes.<br><br>4. I think it's bad idea. It's better to start with<br>examples. <br><br>What really strikes me about haskell is the simplicity of <br>data types. I think the best way to start is to show<br>
Booleans, then lists, then Trees. It's so simple and<br>beautiful<br><br>You can say. Do you really need to know anything <br>about syntax to understand this:<br><br>data Bool = False | True <br><br>or this <br><br>data Time = Time Hour Minute Second<br>
<br>or this<br><br>data List a = Nil | Cons a (List a)<br><br>and you can say that it is not built in. You can define it<br>yourself and it works as fast as any other data type<br>(or as slow). <br><br>You can stress the idea of haskell data types is<br>
haskell UML.<br><br>Don't show definitions just show them types like this:<br><br>not :: Bool -> Bool <br>and :: Bool -> Bool -> Bool<br><br>reverse :: [a] -> [a]<br>map :: (a -> b) -> [a] -> [b]<br>
<br>then you can show definitions and say about pattern matching.<br>It is very intuitive. <br><br><br>[1] <a href="http://hackage.haskell.org/package/atom" target="_blank">http://hackage.haskell.org/package/atom</a><br><br>
<br>