10.22.2010

Not just a talk

I had a talk with one of my fellow students about his project he had to work on while studying and it was quite nice, but rather... unfulfilling in the end let me realize some things about programming and our different ideologies about code. He's a very structured guy and convinced that everything can be solved by using a clear and strict structure in your code, developing top-down in his projects. He didn't quite understood what I was aiming for with my Lisp learning, but I must admit I haven't describes my problems right. We talked about how to solve my problems I had with C++ and it's limited potential for generalization. For example, I wanted n-dimensional coordinates compatible with lower and higher dimensions but also without much code to write while maintaining performance. He suggested to simply make a list of values, it's length representing the dimensions of a vector. That might be ok if you just want make mathematical calculations, but I noticed that even the smallest operation more is a whole of performance differences. He keep his hardlining-alike variant as the most useful to implement (along with the doubtfull features of thus having a varying dimension for each vector without saving it in the structure itself) and didn't seem to worry about the fact that there's an operation more than necessary. I said it's better to write a macro to generate the data manipulation code directly without any loop (seriously, this is the fastest way without unnecessary operations if you don't have dozens of dimensions, which is quite untypical). My point is that it's always more effective to directly generate code if the number operations is limited and not too high. Less operations, faster code. That's it. Even if the necessary operations could be kept to minimum, there is still lost time you could feel with heavy usage of it (and that means 100.000 and more calculation operations per 16 ms). And if you want to put this in a C++ template class combined with types, it's simply not possible to operate with n lines of calculations, dynamically inserted. You can only replace types or extend with other classes (with eliminates a clean structure of clear and useful inheritances). He's too minimalist and too direct in programming to understand the actual of use of it. Of course could I write multiple classes for each dimensions, of course could I make them hook all together and be compatible. But that also means a lot of code, a lot of classes to update if you want a feature that works for all and of course multiple files you can't simply overview. So yes, why don't just use a base class for such operations? Yeah, fine, simply do this, add some template parameters and you'll end up with a huge mess of code just to get it done as you wanted... I already did that, and in a couple of variants. It's too much work, too strict and just not worth doing so. I fuck on this solution.

It's not hard to see why it is suboptimal to take either variant a or b. I like him, but I hate his attitude towards programming. The only way I could ever finish my game (and yes, I'm talking about MY GAME that must have perfect and dynamic and reusable and high performance code within the language's limitation) is to use a better system that allows me to insert only the necessary operations while keeping everything else structured. I have a couple of static sizes and structures (colors, positions, geometry data) and dynamic ones. It'd be the best generalize all these things into one system based on n-dimension grids (not necessarily arrays, some only static components as mentioned). And fuck yes, does nobody see this how obviously this would be? He self said that he doesn't have to time to code it done. It's obvious why, the amount of code required in contemporary programming languages used nowadays is just too high if you want to get performance, too. I would've written it C++ if it would allow me flexibly generate code before compilation. That's why I'm switching to Lisp, to my project possible. I don't think about starting again in C++. It took me years to extend it further, just because I needed to find a way how to express in code. I don't want to develop top-down (and down-top neither, rather inbetween) and limited my code to only one specific task. It's more useful to keep code reusable for later projects. And trust me, ALL my game projects will involve this code. In the end I'll end up with more productivity in coding than he ever will with his limitation. His opinion is that C++ limits to the reason that everything can be done with what C++ can. Fail. Total Fail. Limits aren't so good, except you can't think out of your little box. The future lies in code to generate code to create projects rather than translating concepts to code. This is of course my opinion and I'm not someone who's doing stuff for business people with an already covered of set of solution and every stupid and low-though business shit.

I think in code, he thinks in terms. That's a total difference. Using terms is only useful if there's a fixed structure you can apply. That's so scientific, so... mathematical. And I hate maths, but you probably already knew that... No, it's a different world he's living in. There are so many things differing between our view of programs and code. I'd describe as somebody who's thinking to simply and structured to see what my real problem is with conventional languages and approaches. I can't agree with him, totally not. I want to evolve, not devolve. There's no way one should start thinking in terms of simplification if he's already thinking in generation.

I don't know, I can't help about this. It's just seems to be the difference between how we work and how we see different things. And again, I see myself confronted with the fact that I don't like such limiting approaches. It's good if you know how the game is played, but everything beyond is forbidden by reason that isn't applicable for more advanced concepts. I can't help, I think limiting one's possibilities by too complex restriction systems is lame and degenerated. I'm thankful that there are people out there thinking similar, otherwise I can't explain why languages like Lisp were created and maintained over years. It's twelve years older than C and still survives with success and maintenance. And the more I learn about, the more I understand why. I need this book as a paper version, I even were too late several days, just because I couldn't read it on my laptop on the way to uni and thus read too long at home. I want to master this language as quick as possible. Today's talk with my fellow student brought this urgency of this. The quicker I can get productive with it, the faster I can show him what usefulness and power I mean. There are so many things to do and to show, I hope I can get this book as quick as possible. And hopefully in english, too.

No comments: