 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt
(Yes, you need something that understands M$'s hated PowerPoint file
format...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 <voi### [at] dev null> wrote:
> http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt
>
> (Yes, you need something that understands M$'s hated PowerPoint file
> format...)
yes, when a guy like Tim speaks, developers of toolsets should hear. It's a
good thing that a well-known developer of high profile titles is aware of
functional programming and Haskell and demanding C++-alike tool developers to
provide similar features, like guards and comprehensions...
much of the problems he lists as plagues in the Unreal code have to do exactly
with null pointer deferencing and out-of-bounds arrays, situations which have
no parallel in Haskell...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> yes, when a guy like Tim speaks, developers of toolsets should hear. It's a
> good thing that a well-known developer of high profile titles is aware of
> functional programming and Haskell and demanding C++-alike tool developers to
> provide similar features, like guards and comprehensions...
>
> much of the problems he lists as plagues in the Unreal code have to do exactly
> with null pointer deferencing and out-of-bounds arrays, situations which have
> no parallel in Haskell...
I just find it interesting to see Haskell (which everybody thinks of as
"slow") and games programming (which everybody thinks of as
"speed-critical") in the same document... ;-)
In fairness, Haskell has not (yet) evolved to the point where array
index exceptions can be avoided. (Not by compile-time checking anyway.)
Admittedly, it's a little less serious than the C case (i.e., your
program instantly stops with an eror message rather than randomly
corrupting memory), but that's still not ideal.
Arguably partial functions are the Haskell equivilent of null pointer
issues - as exemplified by "head []". If your code produces this
exception, good luck working out what the problem is. ;-)
I've said it before and I'll say it again - people would probably take
Haskell a lot more seriously if there were big applications written with
it. (The Haskell compiler almost certainly doesn't count.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 <voi### [at] devnull> wrote:
> Arguably partial functions are the Haskell equivilent of null pointer
> issues - as exemplified by "head []". If your code produces this
> exception, good luck working out what the problem is. ;-)
hmm, ok. problem is, there are informations only available at runtime, not
compile time. Perhaps what Tim is asking is for automatic generation of
runtime tests for these common situations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> Arguably partial functions are the Haskell equivilent of null pointer
>> issues - as exemplified by "head []". If your code produces this
>> exception, good luck working out what the problem is. ;-)
>
> hmm, ok. problem is, there are informations only available at runtime, not
> compile time. Perhaps what Tim is asking is for automatic generation of
> runtime tests for these common situations.
There are various manual and automated test systems for Haskell. It's
not something I've looked at. It's also possible to do crazy things
using experimental language extensions to (clumsily) encode the length
of a list into its type, thus allowing it to be checked at compile-time,
but this becomes messy rapidly [since the language isn't supposed to
support it]. Apparently there are programming languages that have this
as a design goal... and they're even rarer than Haskell. (If you can
imagine that...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> much of the problems he lists as plagues in the Unreal code have to do exactly
> with null pointer deferencing and out-of-bounds arrays, situations which have
> no parallel in Haskell...
In C++ it's possible to create more abstract arrays and pointers which
are equally easy (if not even easier) to use than the native equivalents
and can be compiled to be equally fast.
The advantage of this abstraction is that things like bound checks and
null pointer checks can be added to them.
If the company has developed a robust library of abstract libraries and
then imposes strict rules on the coders (like "never do a 'int table[100];'
but always do a 'OurArray<100> table;'") then most of the problems can be
quickly caught in testing.
The great thing is that during debugging and testing a version of the
library with full checks can be used, and when the final product has been
tested to death, then a version of it without the checks (for efficiency)
can be very easily compiled for distribution.
So you get the best of both worlds: Null pointer, array boundary and
other types of checks at debugging and testing, full speed at release.
The main obstable in achieving this are stubborn programmers who resist
change and who suffer from the C-hacker-syndrome.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> functional programming and Haskell and demanding C++-alike tool developers to
> provide similar features, like guards and comprehensions...
http://www.rubinsteyn.com/template_insanity.html
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> So you get the best of both worlds: Null pointer, array boundary and
> other types of checks at debugging and testing, full speed at release.
You do realize that this isn't in any way unique to C++, yes? :-) I
mean, without even writing two versions of the library?
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> http://www.rubinsteyn.com/template_insanity.html
Template metaprogramming is really mean to compilers. This is because
template metaprogramming is in practice functional programming where loops
are made exclusively by recursion. Recursions need stacks or other forms
of keeping track of where we are, and thus the memory usage is proportional
to the number of recursions. (In many functional languages tail recursion
can be optimized internally into a non-recursive loop, but you can guess
if C++ compilers support the notion of "tail recursion" with templates...)
In template metaprogramming a recursive loop means in practice that the
name of the templated type is very long (each "loop" makes the name longer).
Most compilers have a fixed amount of memory allocated for demangling
template types. Thus they support only a very small amount of recursions.
In some compilers you can increase this limit with a command-line parameter
(eg. gcc supports this), but it's still fixed.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> You do realize that this isn't in any way unique to C++, yes? :-) I
> mean, without even writing two versions of the library?
Yet C++ is used to make games and those other languages aren't. Why?
(Perhaps one advantage of C++ is that there are millions of libraries
out there written in C, and they can usually be used in C++ as they are,
without any modifications. Few other languages can do that.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
