Development speed...

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|71\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> C/C++/C#/Other -> Development speed...
Sat, 14 Jan 2012, 15:22
Afr0	So, I've been chatting with a fanboy on Facebook and trying to explain to him the futility of trying to rebuild the work of 52 (I counted!) programmers (not including Technical Directors) in C++ and OpenGL. One of the programmers who broke off from TSO-R, or Project Dollhouse, is trying to do the above. And it got me thinking... I think we've all heard that C# and Java will get you there faster than C and C++, but has anyone ever actually done any measurements, not in execution speed, but in development speed? I tried Googling, but couldn't come up with any answers... If it helps, I'm using XNA. Which also should help quite a bit. I have the option of using DirectX and OpenGL as well, but... well... it's stupid, as far as I'm concerned. I'm used to working with XNA and it's faster. For a project of this magnitude, development speed is critical. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Sat, 14 Jan 2012, 15:45
spinal	I think dev speed really only boils down to how well a programmer knows their chosen language. I can knock out a game in BASIC way faster than I can in say C. Not because the language is any better or easier to learn, but because I learned more of it and can recall more if it when I need to. -=-=- Check out my excellent homepage!
Sat, 14 Jan 2012, 15:49
Afr0	I really doubt that. The difference would probably be smaller from say, BlitzMax to C# and XNA, but right now the Project Dollhouse client is around 14,000 lines (including comments), and I would not be surprised if it would take at least 20,000 lines (including comments) to do the same in C++ and DirectX (or OpenGL - I believe the difference there isn't so big). Note that the client also includes SimsLib which deals with all fileformat operations. Though the thing about C++ is that you have many options... it would be interesting to try to write a QFS decompresser using the Win32 API and the C++ STD and see which would be the longest program (one must assume that whichever program is the longest took the longest to write). -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Sat, 14 Jan 2012, 17:12
Jayenkai	No, I agree with Spinal's thing. You're quick at things because you've gotten used to them. It's like that guy who draws a picture a day.. (is he still doing that, btw?!) He starts with squiggly doodles, but ends up with gorgeous artwork. He's not getting faster because he's bought £259473 art tools, he's faster because he's getting used to the tools he has, and is getting more accustomed to using them. Coding's the same. Stick to a language, get better. You'd be quicker using C#/.net/something modern. Me and Spinal would be quicker using Basic. There's no right answer. There's only an answer that's right for you. -=-=- ''Load, Next List!''
Sat, 14 Jan 2012, 19:37
JL235	I partly agree with Spinal. Roller Coaster Tycoon was entirely written in assembly, and the reason was solely because the developer (Chris Sawyer) really liked writing in assembly. It wasn't for performance or any other reason then that. I remember when I used Erlang for my third year project. It's a language regularly cited as having far higher productivity speeds then Java, C# or C++. However overall I found I was much slower with Erlang then Java. In fairness, that is partly because Erlang works quite differently, which I was not used to. Many of the productivity speed ups are mostly around building concurrent applications (and Erlang is much faster for that). My opinion: if you know a language inside out, then you'll be more productive in it. However if all things are equal, then language X will be faster then language Y. But it's not all about language either. If I want to build a GUI, lets say a calculator, it'll take me much longer to build it in Java then with JavaScript/HTML/CSS. That is because Swing, the library for building GUIs in Java, is much more time consuming then HTML with CSS. Building even simple layouts takes a lot of code, and it's more complex then using HTML/CSS. Finally, productivity is not all about development time. In any real project a big proportion of your time is spent on maintenance; fixing bugs, changing features, and updating sections. Any language that can make this side faster, will improve productivity. This is an area where functional languages, such as Haskell, are often cited as a big win. Typically they take much longer to master, and can take longer to develop in, but the code produced is ends up being more flexible and less buggy. The reason is that in a functional language you have to expose the 'side effects'. A 'side effect' is when a function does more then just return a value; such as printing text to the command line, drawing to the screen, or updating a variable outside of the function (like a global). In C#, any function can print out text, at any time. This means you don't really know what a function will do until you call it. In Haskell, side effects, and in this example IO, must be explicitly passed in and explicitly returned. As a result you have far more confidence about what the function is doing. If it takes and returns IO, it must be printing text to the command line. If it doesn't, then it will not. As a result you have far more confidence about changing code, or calling a function. If there are no side effects listed, then none will occur.
Sun, 15 Jan 2012, 01:44
Afr0	But it's not all about language either. If I want to build a GUI, lets say a calculator, it'll take me much longer to build it in Java then with JavaScript/HTML/CSS. That is because Swing, the library for building GUIs in Java, is much more time consuming then HTML with CSS. Building even simple layouts takes a lot of code, and it's more complex then using HTML/CSS. I think the same difference exists between C# and C++ as well. Or at least XNA and DirectX. Not sure about OpenGL. Though the main advantage with XNA is that it covers many more areas, such as input, sound, and fileformat handling (whereas with OpenGL you have to use something like libpng to load pngs). I'm already using an external library for sound, but what I'm doing in terms of sound right now is minimal anyways. In general, though, I think you can safely say that any external library you have to learn to use will cost you more time. I'm also using Lua to speed up the development process, and I do believe it helps. If I were to have written all the UI code in C#, the codebase would be messier, less structured, and would have taken longer to write. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Sun, 15 Jan 2012, 02:17
JL235	Afr0 I think the same difference exists between C# and C++ as well. Or at least XNA and DirectX. Not sure about OpenGL. Though the main advantage with XNA is that it covers many more areas, such as input, sound, and fileformat handling (whereas with OpenGL you have to use something like libpng to load pngs). It's apples vs oranges. OpenGL can't really be compared to DirectX, as it's an umbrella for various libraries, which includes Direct3D. That is what OpenGL can be compared to. Direct3D can't do the things you've listed either. You can use the other DirectX/Windows libraries with OpenGL too, and game developers do.
Sun, 15 Jan 2012, 16:02
Afr0	Just for the sake of comparison I will post my ported code for decompressing UTK (UTalk) files once I've confirmed it's working. In this case, he'll have spent much more time than me anyways because he was the one who actually documented the format by reverse-engineering the original client, but at least we'll get a length to length comparison between C# and C++. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!