Jump to content

  • Log In with Google      Sign In   
  • Create Account

spinningcube

Member Since 22 Oct 2007
Offline Last Active Oct 17 2014 02:07 PM

Posts I've Made

In Topic: I have some new habits.

10 April 2014 - 07:15 AM

 

I have a much easier time thinking of someone with a background with a function based (not functional lambda calculus) experience like C/Pascal will do a better job at designing software than someone with a (bad) OOD background. He or she would use the modules approach of Pascal and apply it to OOP and we would all be happier for it.

 

I'm sure a bad designer would produce crappy work no matter the methodology. Granted, OOP gives you a richer set of tools to introduce strange and unnecessary relationships, and in that case sticking to C/Pascal might give you some damage control.

 

You need an experienced designer willing to take the time to constantly re-evaluate the design as the system grows.

 

 

I am always trying to improve and to know more about OOD (a new improved way) is always interesting.

 
I highly recommend Evans Domain Driven Design. Beware that it's not a beginners book. Although it has a lot of patterns (OODish or whatever you want to call it), I think the main point is more the process or rather mindset when designing large software systems.

 

 

Exactly re-evaluation is one of the most interesting skills in a designer and it is easier implemented if the core architecture is also agile (not as in agile development) meaning re-adaptable.

 

Sometimes though with very complicated object oriented designs it is better to just start over from scratch. That is also true of non-object oriented though. However with time pressures on projects this is often left unattended and many times a system that would better be scrapped and re-coded in 2 months takes 6 months of artificial life support before it finally is re-designed. However most of the time when this re-design is then done, the manager at a higher level then demands a "grand" design which of course will make the cycle repeat. But now we go into politics rather than technical parts of it. Sometimes I think it's better to show a grand design scheme to management with lots of intricate arrows and boxes and have a an actual simple implementation for the running system ;-)

 

Thanks for the ref, will have a look :-)


In Topic: I have some new habits.

10 April 2014 - 05:10 AM

 

(To the guys (as a group) that try to oppose the obvious. Not the OP who is caught it in the crossfire.)

 

If you still don't get it after my posts and the post of hodgman, I am at loss of words.

 

Hang in there some 10+ years and then get back to me.

 

Cheers,

 

Spinningcube

 

PS - and then you can buy me a beer ;-) No hard feelings fellows. You just don't want to get it.

 

PS2 - Pro tip. Look me up and see what I have achieved. Then think.

 

*sigh*

 

I'd suggest you stay in academia, old sport. Probably the only place you can stay afloat based on skills and experience alone. In the real world, being rude, arrogant and patronizing works against you regardless of your certificates.

 

Its a shame. You'd be a great learning resource if you were able to interact well with others.

 

 

Haha! Working on it. Thanks for the backhanded compliment ;-)


In Topic: I have some new habits.

10 April 2014 - 05:02 AM

Very cool explanation Hodgman,

 

For the OOP/OOD debacle I think it is because I have seen much bad OOP code in production systems (I have had my own company since 2006, but admittedly I always have a strong bond to academics, I want to improve scientific data visualisation) and with lots of zealots marrying themselves to concepts that you say (inheritance for re-use, coupling, over-use of templates etc.) where they are "experts" but only experts in making the code more bloated, harder to understand and hard to extend.

 

I've seen this so many times in companies that I think it boiled down to the fact that the designer wanted to have job security by designing something overly complex and that management would never dare to touch. I have also been part of such management and seen it pushed on me.

 

I have always pushed for independent code blocks, modules and as much as possible data oriented programming not because it gives better performance (but sometimes does, in fact most of the time does as access is often linear and sequential (but that is another discussion)) but because it it allows for clean decoupling almost treating the code as some kind of scripting language doing transformations on data.

 

So yeah, when I see clean OOP code I am more than often surprised and it is mostly because the person has gone though the zealot years of OOD (what you call badly taught OOD and I agree, just that it is so dominant right now it is hard to say what is good OOD) then came out "cleansed" of such over complicated notions and has a better flexibility with design and thinking about programming.

 

I have a much easier time thinking of someone with a background with a function based (not functional lambda calculus) experience like C/Pascal will do a better job at designing software than someone with a (bad) OOD background. He or she would use the modules approach of Pascal and apply it to OOP and we would all be happier for it.

 

I am always trying to improve and to know more about OOD (a new improved way) is always interesting.


In Topic: I have some new habits.

09 April 2014 - 04:29 PM

(To the guys (as a group) that try to oppose the obvious. Not the OP who is caught it in the crossfire.)

 

If you still don't get it after my posts and the post of hodgman, I am at loss of words.

 

Hang in there some 10+ years and then get back to me.

 

Cheers,

 

 

PS - and then you can buy me a beer ;-) No hard feelings fellows. You just don't want to get it.

 

PS2 - Pro tip. Look me up and see what I have achieved. Then think.


In Topic: I have some new habits.

08 April 2014 - 12:03 PM

 

http://www.insomniacgames.com/three-big-lies-typical-design-failures-in-game-programming-gdc10/

I actually took the time to read the PDF out of curiosity (though, it is kind of misleading to post two links, when one is just a couple paragraphs and a link to another).

 

What I got from it is completely different from what you are saying.

[...]

 

None of what he was saying is bashing OOP, in my opinion. Referring back to the aforementioned example of a key => value dictionary, he didn't advocate getting rid of the object entirely, just redesigning how it works on the inside; the interface may even go unchanged!

 

 

So then why is the author summing it up with?

 

(Lie #1) Software is a platform
I blame the universities for this one. Academics like to remove as many variables from a problem as possible and try to solve things under "ideal" or completely general conditions. It's like old physicist jokes that go "We have made several simplifying assumptions... first, let each horse be a perfect rolling sphere..."
 
The reality is software is not a platform. You can't idealize the hardware. And the constants in the "Big-O notation" that are so often ignored, are often the parts that actually matter in reality (for example, memory performance.) You can't judge code in a vacuum. Hardware impacts data design. Data design impacts code choices. If you forget that, you have something that might work, but you aren't going to know if it's going to work well on the platform you're working with, with the data you actually have.
 
(Lie #2) Code should be designed around a model of the world
 
There is no value in code being some kind of model or map of an imaginary world. I don't know why this one is so compelling for some programmers, but it is extremely popular. If there's a rocket in the game, rest assured that there is a "Rocket" class (Assuming the code is C++) which contains data for exactly one rocket and does rockety stuff. With no regard at all for what data tranformation is really being done, or for the layout of the data. Or for that matter, without the basic understanding that where there's one thing, there's probably more than one.
 
Though there are a lot of performance penalties for this kind of design, the most significant one is that it doesn't scale. At all. One hundred rockets costs one hundred times as much as one rocket. And it's extremely likely it costs even more than that! Even to a non-programmer, that shouldn't make any sense. Economy of scale. If you have more of something, it should get cheaper, not more expensive. And the way to do that is to design the data properly and group things by similar transformations.
 
(Lie #3) Code is more important than data
 
This is the biggest lie of all. Programmers have spent untold billions of man-years writing about code, how to write it faster, better, prettier, etc. and at the end of the day, it's not that significant. Code is ephimiral and has no real intrinsic value. The algorithms certainly do, sure. But the code itself isn't worth all this time (and shelf space! - have you seen how many books there are on UML diagrams?). The code, the performance and the features hinge on one thing - the data. Bad data equals slow and crappy application. Writing a good engine means first and formost, understanding the data. 

PARTNERS