[karajorma]

I'm not saying you have to remember how to access the data yourself, just that when you're picking between a vector and a linked list all the information you really require is how fast they are at certain tasks. That sort of information tends to appear in the documentation. For instance, the docs for ArrayList here.

The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation.

Why would I need to know more than that?

[Ghostavo]

For what you are asking, most probably not. But if a someone knows what O(n) is, most likely they are not the ones the article author is referring to.

I apologize for my tone earlier, sometimes it's hard being the only one on one side of the discussion.

[karajorma]

Fair enough. I understand it's easy to lose tempers.

When it comes to stuff like which collection class to choose though, you don't even need to understand O(n), just that one is better at one thing while the other is better at something else will get you pretty far.

[sigtau]

Eight years of teaching myself how to code in as many mainstream C-like languages as possible, and I'm already considering diverting my college major altogether after reading this thread.  And I haven't even graduated high school yet >_>

On the topic of the original post: I've noticed this in the coding community like myself, but I wonder if the confusion doesn't arise from the fact that the same basic skill is shared across the board: we all have to know how to create an abstraction of a problem so that we can solve it in a precise, logical manner, whether we're scripting in PLSQL for a giant corporate database or sitting in our parent's basement, pounding away at the keyboard to create a Java library that can perform arithmetic operations on dates and times.

Perhaps, because we all have the same core approach to figuring out a problem (abstraction), we think we're all equally qualified to do each other's job, even if we're not specialized the way they are?

[blackhole]

The problem here is that there is no end to programmers that foolishly insist that you just need to read the documentation to know how to code something. This is demonstrably false as soon as you start solving anything other than easy problems. There is no way anyone with no experience in graphics can do my job, and I know this is true because I've seen idiots attempt it and fail miserably over and over and over. There is an endless stream of morons who continue to try to tell me to do stuff that simply doesn't work because they aren't aware of memory bandwidth bottlenecks or cache coherency. No programmer can just go and write a lockless data structure without an incredibly deep knowledge of low level CPU operations because you have to know where to enforce memory barriers to prevent the CPU from re-ordering instructions in a way that breaks the data structure. This isn't stuff you can just pick up in a month. I've tried. All I can do is write a one-sided locking mechanism without using semaphores, which is pathetically easy in comparison to writing an entire lockless data structure. And then there's the fact that lockless data structures are only sometimes useful and you have to know when to use them properly. This stuff matters.

That didn't stop approximately 300 people from telling me that I am a complete idiot and should never program anything ever again.

[Dragon]

Wait, you also have graphics skills? 
You never cease to amaze me, Blackhole.
Are you a modeler, or a 2D artist? Because if your art is as good as your music, you could really help some projects in here.

[blackhole]

By "graphics" I mean I'm a graphics programmer I'm a terrible artist in both 2D and 3D. I can do some manipulation, but that's purely because I know the inner workings of all the graphical theory behind the programs.

I'd be too busy to help, anyway.

[Dragon]

Ever considered tackling SCP? If your coding is as good as your music, FSO would look better than X: Rebirth in no time.

[blackhole]

I actually did try once. I went in and attempted to upgrade DirectX only to be repulsed by the horrendous Cthulhu-code monstrosity that still haunts my nightmares. It would quite literally be easier for me to just write an entire new engine than try to fix that mess. Also I hear you have another graphics programmer putting in stuff like shadows already. Plus, still don't have time to do it anyway.

[jr2]

blackhole, maybe it would be easier to port the functional OpenGL code that we have into a new DirectX code?    Ok, ok, I don't know what I'm talking about, just throwing the idea out there.

[blackhole]

I'd have to look at the code again. The last time I looked at it was 5 years ago. This is unlikely to happen due to me being entirely too busy to help with the project anyway.

[Tomo]

blackhole, maybe it would be easier to port the functional OpenGL code that we have into a new DirectX code?    Ok, ok, I don't know what I'm talking about, just throwing the idea out there.

I don't think that's a good idea because FSO is cross-platform.

DirectX is only useful on Windows and XBOX platforms (and possibly Windows Phone if anybody cared) - ok, WINE support is getting quite good but still.
OpenGL does everything (graphical) that DirectX does and is also cross-platform.

Thus re-implementing DirectX would be a waste of a good graphics programmer. (To be honest, unless you're targeting the XBOX I think even learning DirectX is a waste of time these days.

However, updating the OpenGL implementation, cleaning it up, removing the deprecated calls etc?
Now that's worthwhile - and will probably result in notable performance improvements for everybody.

[blackhole]

If the openGL already exists I tend to agree with Tomo. I personally prefer directX over openGL because its less retarded, but I usually think most graphics engines should implement both for a variety of reasons. It's still irrelevant because you guys will never get me to help

[Nuke]

how is direcx less retarded to opengl? directx has has piss poor reverse compatibility, ms doesnt want to support more than one or two generations of legacy applications. and on top of that ms has been deprecating parts of it and replacing it with lesser code from the xbox line (like direct input, getting replaced by xinput, not really graphics related but is still a major issue with me). i have not touched direct3d but opengl is elegant and easy to learn. i have not seen any of this retardation that you speak of.

[blackhole]

Meanwhile OpenGL has a crapton of legacy cruft too. This answer is more of a history lesson but it points out a lot of the issues I had with openGL back when I started building my engine in DX9. Since modern engines now use DX10/DX11 vs. openGL 4, I don't know which issues have been solved and what new issues have arisen, but I have little faith in either openGL or directX, since both of them have certain issues that keep coming up and making things extremely annoying, and they are almost never addressed, or they are addressed very badly. DirectX still ends up being easier for me to use due to its object-oriented nature meshing nicely with my engine design, which is why I prefer it over openGL. If you don't, then more power to you. I don't really care.

[Nuke]

id rather have a bunch of legacy cruft than piles of old games that i can only run on a hand full of operating systems. i have a distinct loathing of directx 5,6,7 and sometimes 8 games, because of how many bugs they have when you try to run them on a modern operating systems. i have an entire collection of games that i just cannot play because they were made for those versions of direcx. i can run even older opengl and even glide games just fine. not to say ive had any issues running 9 through 11 games. i just dont trust ms to preserve more than a couple years (or a couple windows versions) of backwards compatibility, while opengl has proven itself reliable in the long term.

any other reasons i might not like directx, really have nothing to do with d3d at all, but the other aspects of directx (like the deprecation of direct input for the inferior xinput, as i mentioned earlier). im sure both have their quirks, so im not looking to start an api war. i should also add that i played glide games long before i ever played d3d or opengl games.

anyway im gonna read that article because im sure its got sone important stuff in it, but the second it starts being biased im closing it.
meh it was an ok read. i can say that i like opengl for the same exact reason why everyone else hates it. opengl is still important, because without it all those other platforms wouldnt have an api (i doubt ms is going to make any api open enough to be used on all platforms). il just stick to opengl and sdl for all my 3d development in the near future.

[Tomo]

The reason I think you're daft to learn DirectX (Direct3D) instead of OpenGL is very simple - it's the small things.

Portable devices like phones and tablets almost exclusively use OpenGL ES 2.0, which is Open GL with nearly all the legacy cruft removed.

Thus if you learn OpenGL ES, you've learnt the vast majority of what you need for all PC (Windows, OSX and Linux) environments and the rather large mobile segment.
- Yep, you heard right. In theory, it should be possible to port FSO to your phone.

(Whether it's feasible or anyone has the time to do it is quite another matter.)

[blackhole]

Obviously if you want to be portable you should be learning openGL. That doesn't mean openGL is easier to use or better designed than DirectX. It's just a reason to suck it up and learn all its stupid, ****ty ways of doing things because it works on everything.

It's kind of like using Java instead of C# because you want to torture yourself with its incredibly bad tools so your program works on everything.

[z64555]

Just try out both and let us know what ya think of it. Done deal.