Vertex[] Transform (Vertex[] Vertices, int[] Indices, Matrix m)
{
    Vertex[] Result = new Vertex[Indices.length];

    for(int i=0; i<Indices.length; i++)
        Result[i] = Transform(m,Vertices[Indices[i]]);
    return Result;
};

Quote:

Original post by remigius My problem with this? Well, for starters points 3 and 7 are duplicates, just like points 2 and 6.

Quote:

A C# foreach statement would take care of point 5.

Quote:

The null-reference exceptions can be trivially caught using assert statements or with if statements, should more elaborate action be neccessary.

Quote:

So the issue that an index in the Indices array may be greater than the size of the Vertices array is the only non-trivial problem with this code. You could just wrap the Indices array in some class which can perform the max index check and when implemented correctly, I doubt it would be much slower than the Haskell nat<n indicator.

Quote:

If someone could elaborate on these properties of Haskell, I'd be genuinly interested to hear more about them. As far as I can tell now, I'd say the abstraction of these kind of performance intensive operations in simple looking, (over-?) expressive statements is a dangerous property for realtime graphics programming and realtime programming in general.

Quote:

C# might not have this sort of feature built-in, but it isn't too hard to write this check yourself.

Quote:

Edited: and as a coupe de grace on this code snippet, issue number 4 can never happen, as the Matrix object in MDX is instantiated from a struct and as such can never be null, since it's a value type... Bit of a painfull mistake there, I'd say... Maybe nitpicking, but when someone's trying to make his point at the expense of C#, I'd think a bit more research might have been warranted.

Quote:

Original post by superpig The point is to give the compiler or static analysis tools the information they need to ensure that the value could never be out of range

Quote:

As far as I know that's not possible with procedural languages; the best we've got in procedural languages are things like loop invariants, and that leaves a lot of things to chance.

Quote:

I notice on the PPT that 6 and 7 are in a different colour to the rest, which makes me wonder if he doesn't already know that they're duplicates

Quote:

No, point 5 is saying that i is guaranteed to be less than the size of the array, but that it's difficult for a compiler or other static analysis tool to discern that. How does a foreach help?

Quote:

The nat<n thing isn't Haskell, it's his own pseudocode thing. That said, I think the point is not that it will be continually verified at runtime or anything like that. The point is to give the compiler or static analysis tools the information they need to ensure that the value could never be out of range, i.e. you can't assign from a generic "number" type to a "nat<n" type without going through "round" or "truncate" and "clampToRange" functions, because the types are different. Static typing, y'know?

Quote:

The massive advantage of functional languages like Haskell over something like C# is provability. You can prove, through methods like proof by induction, that a function is correct and will always be correct for any input.

Quote:

It's worked well enough for Wings 3D, which while not written in Haskell, was written in another functional language (Erlang).

Quote:

Provided you remember to. And as the man said, 50% of the bugs in Unreal can be traced to forgetting to initialise variables, or forgetting to check that a pointer is not null before dereferencing it, or forgetting to check that an array index is out of bounds. None of these things are hard to do in and of themselves but if you find yourself having to remember to do it everywhere then it's only a matter of time before you start missing spots.

Quote:

Who said it was an MDX Matrix object?

Quote:

Original post by remigius Again, I agree to some extent, but it's a bit of a dubious point to make. Having a language guard against this undoubtedly has some significant performance implications, though they're all rather exceptional cases of things that could go wrong. It's the choice again between performance-friendly try/catch blocks or guarding against this as a language facility.

Quote:

Original post by sebastiansylvan No. He was talking about static guarantees. That means there's no performance hit whatsoever. It would be way cheaper to use static checking of indices rather than having to use runtime bounds-checking and exceptions. Everything he talks about are things that are verified at compile-time (which means that the run-time code can be much more efficient).

Quote:

And as the man said, 50% of the bugs in Unreal can be traced to forgetting to initialise variables, or forgetting to check that a pointer is not null before dereferencing it, or forgetting to check that an array index is out of bounds. None of these things are hard to do in and of themselves but if you find yourself having to remember to do it everywhere then it's only a matter of time before you start missing spots.

Quote:

And like he said. Even if this language runs several times slower than fully tuned C code, it's still a win. Higher productivity and reliability means you can put more of the system to good use. If you can employ all six threads in the Xbox360 100% of the time, then you're still going to be faster than your typical C++ style application which probably won't be anywhere near full utilization.

Quote:

Original post by remigius Quote: And as the man said, 50% of the bugs in Unreal can be traced to forgetting to initialise variables, or forgetting to check that a pointer is not null before dereferencing it, or forgetting to check that an array index is out of bounds. None of these things are hard to do in and of themselves but if you find yourself having to remember to do it everywhere then it's only a matter of time before you start missing spots. I'd say checking against these issues cannot be done completely at compile-time. Some obvious cases may be intercepted by the compiler (as the C# compiler also already does) but most of these checks on function parameters would need to be done at runtime (null reference checking and reading index data from a file into a limited range type both would, for example), which will produce a runtime overhead.

Quote:

With the foreach loop you completely eliminate the indexing i variable, thus removing this whole point. If you scroll down the PDF to the Haskell/pseudocode snippet for this example, you'll see mr. Sweeney uses a for each loop there to eliminate this point too.

Quote:

However, you'd need to define a seperate static type for each size of vertex array, or am I missing something here?

template<typename T, int size>;
class FixedArray
{

 T internalArray[size];

 public:
 typedef DependentNaturalNumberTypeThatIsNoBiggerThan<size> Index;
 T& operator ()(Index idx)
 {
   // no need to check for an out-of-bounds situation because idx is guaranteed to be in bounds
   return internalArray[idx];
 }
};

Quote:

Original post by superpig How does one code like this, you may ask? Haskell does it using pattern matching. A variable of the "maybe" type can only match two expressions: "Maybe A" or "Nothing," where 'A' is a parametrized type (i.e. "Maybe Int" or "Maybe Char"). So you effectively write two versions of the function, one to be used when the argument matches "Maybe A" and one to be used when the argument matches "Nothing." It's sort of akin to an if-not-null conditional expression except that it has this kinda implicit type conversion built in; because the argument is guaranteed to match the pattern, you can safely access subcomponents of the pattern (i.e. the 'A') without worrying about whether they're actually there.

Quote:

OK, so modify his example a little to have the function only transform the first N indices.

Quote:

Many types can be implicitly defined instead of having to be explicitly stated. It's almost like templated typedefs:...

Quote:

Original post by Calefaction A good programmer is a good programmer, regardless of the language you stick in front of them. Trying to say one language, or one type of language (procedural or functional) is always going to do X, Y and Z the best is foolish and very subjective.

Quote:

Original post by remigius You might be able to remove all these problems with a sufficiently expressive language, but for the vertex/indexbuffer example you'd still need a type with a range that is unique for the size of the vertexbuffer. This may be done incredibly efficiently and it would make the function certainly idiot proof, but I'm having some doubts if the language would really need to go 'that far' with its facilities.

Quote:

Original post by remigius I'm a bit of a mess with C++ typedefs and templated classes, but wouldn't this still mean you have to define the DependentNaturalNumberTypeThatIsNoBiggerThan type somewhere?

Quote:

I can imagine that a compiler can be made to recognize assignments that fall outside the lmited range of the type at hand, but this still won't solve the runtime check of reading in these numbers from an external source like a file, which should be a common operation on the proposed use of vertex/index buffers.

Quote:

Original post by remigius As I'm trying to break out of my newfound tunnel vision, I can imagine that a compiler can be made to recognize assignments that fall outside the lmited range of the type at hand, but this still won't solve the runtime check of reading in these numbers from an external source like a file, which should be a common operation on the proposed use of vertex/index buffers.

Quote:

Original post by sebastiansylvan Quote: Original post by Calefaction A good programmer is a good programmer, regardless of the language you stick in front of them. Trying to say one language, or one type of language (procedural or functional) is always going to do X, Y and Z the best is foolish and very subjective. A good race car driver is always going to be a good race car driver. However, he will be able to do much more if he's driving a driver-friendly car. Obviously someone who's a bad race car driver won't be magically better because they get to use a good car, but it certainly doesn't hurt. People get way to fussy about their languages. They're not religion! Just tools! Learn many of them, and use the ones you like best for a particular task. There are no silver bullets, but that doesn't mean that the language you use doesn't matter. It's just irresponsible (or stupid) to use an older, less powerful, language if better alternatives exist. Developing games is costly, we need to use better tools wherever we can find them. Most projects spend over 50% of the programming-time in correctness-related tasks (debugging, writing unit-tests, etc.), how come so many programmers (who are usually good at finding out what to optimize when it comes to code) are reluctant to use languages which emphasize correctness and reliability? It's obvious that this is where the big productivity savings could be achieved, yet so many refuse to even try some of the languages out there (and experience the huge difference for themselves). Some companies do meassure it though. Ericsson meassured a productivity boost of 9-25x when switching from C++ to Erlang (depending on the metric you use, IIRC the 9x was LOC/hour, whereas the 25x was features/hour). I certainly don't want to get into a language flame-war here. But saying that Tim is somehow "biased" against procedural languages is pretty far-fetched. What would be his motive for disliking procedural langauges? (I'll tell you: real-world experience writing one of the most widely used engines in C++, and a sound attitude towards languages - they're just tools, not religion).

Quote:

Original post by Calefaction Most professional programmers are extremely familiar and comfortable with the "C-style programming model". Asking them to magically change because you or some professor at a school (or even Tim Sweeney) says so is not going to work out real well.

Quote:

For that matter, how hard is try/catch to use? Did it suddenly become difficult overnight and I missed it?

Quote:

When that starts getting abstracted away in these wonderful blackbox language features, it isn't helping the trully skilled developer. It's limiting them.

Quote:

Original post by Calefaction But if you put a race car driver in a faster car that he isn't comfortable with, he is just as likely to go slower than if he was in his slower car that he is comfortable with.

Quote:

Not enough credance is given to level of comfort and knowledge.

Quote:

If we both get the same job done in the same relative amount of time, then I really don't want to listen to your rhetoric about how good Black and Decker saws are...my Mikita is working just fine for me.

Quote:

You can't expect developers to want to up and change their comfort zone simply because you think this language or that language gives them this massive productivity boost.

Quote:

For all the hours I gain by not having to use try/catch, how many am I going to lose having to re-orient myself and make myself comfortable with this new language you pushed at me?

Quote:

Asking them to magically change because you or some professor at a school (or even Tim Sweeney) says so is not going to work out real well.

Quote:

For that matter, how hard is try/catch to use? Did it suddenly become difficult overnight and I missed it? I don't want every method/function in my code to explicitly be wrapped in training wheels to check for every possible error condition, static or otherwise.

Quote:

Part of being a programmer is know when to use a certain nut or bolt and when not to.

Quote:

When that starts getting abstracted away in these wonderful blackbox language features, it isn't helping the trully skilled developer. It's limiting them.

Quote:

perhaps we should let people use the tools they are most comfortable with, rather then coming in and telling them their tools are inadequate and replacing them because you think it's more productive.

Quote:

Original post by MichaelT Personally I have had troubles dealing with multithreading in C++ but it's not exactly impossible either. I understand his points, but I'd much rather extend C++ to fix what needs fixing than inventing yet another language.

Quote:

Original post by sebastiansylvan How are you going to extend C++ to fix its problems? I mean, without removing anything the problems are still going to be there for most of the reliability and concurrency problems. IMO it's better to just drop this 30+ year old legacy and start afresh. C++ is already so complex that there aren't any implementations which fully implement it (to my knowledge, at least) -- adding even more stuff to it, which would undoubtedly clash with some existing features, is probably too messy to be doable.

Quote:

Original post by MichaelT Ask yourself: What is the cost of leaving C/C++ for another language? What new problems are there? How do I design this new language? How do I gain support for it? How can I get 3rd party tools to support it? Etc. Those are but an initial amount of endless questions. You basically said it yourself, C/C++ is 30+ years old. That is a lot of beta testing, solutions to problems, IP investment etc... Starting something new is not as simple as you might think.