I want...

A language that:
- Can be compiled to native code.
- Can use OO abstractions.
- Is not Java.
- Is not C++.
- Is not C#.

What I am searching for?

>>118
And yes, it does sound like a bad design. Your entities should probably not use reference counting... reference counting is more for like a group of entities or larger subsystems.

If I were implementing your game, I'd be using the structure of arrays approach, using homogeneous arrays for each entity field/component. Removing an entity would just involve setting a flag, and at a synchronization point during the update pipeline, I would remove the entity by copying the remainder of each array over the entity offset and decrement the entity count.

No reference counting. The entity system/scene graph has strong ownership of the entity arrays, which are generally allocated at load time and have a fixed upper bound.

If you need an object-oriented class to coalesce all of the fields from each array for a particular entity offset/id, just create a simple object-oriented view abstraction, similar to how you can create views in RDBMSes.

This is the data-oriented approach which is popular among professional game developers for modern games. It's fast as fuck, it's easier to parallelize, and doesn't thrash the cache or fragment your allocators. It also usually ends up being less code too than an more OO approach.

Fine-grained object-oriented factory systems for entities/game objects is the amateur design.

>>116
Most software that deals with database are boring and trivial enterprise software.

hint: almost all software is essentially pretty trivial. SQL is a functional domain-specific programming language that lets you deal with databases in a trivial fashion. A C++ solution that used no other (superior) technology would turn it into a non-trivial application, just like it does everything else. Triviality is more often dependent on accidental complexity and implementation than it is on essential complexity and the real problem. If you think in C++, you probably have no idea what I'm actually talking about.

Wtf? Why sould I believe you. Do you have any proof? Have you tried designing your code better?

I used to be a C++ fanatic. I saw the light. Here's the thing: when you use a C++ style to design code in a language with proper closures, you get an unmanageable mess (actually, this is what most Java programs are,) and vice versa. So those two positions of the grid are obviously bad. The comparison is C++ style in a C++ program vs closure style in a closure language, and it's not even close. I have literally written code before and thought "the C++ way to solve this (ie not to translate what I'm doing but to do it the legit C++ way) would be 10 times as much code." This is NOT bad design. Less code is always fewer bugs, _easier_ to optimize (provided you can go native,) and easier to manage. For instance, it's actually worth using dynamic typing because your code will be that much smaller that you wan't need static analysis to understand what's going on. I know it's hard to believe, but it's true.

GC encourages programmers to code badly without understanding what affects to the performance.

Am I being trolled? It's true that GC lets you forget about a lot of bullshit that you need to do to write good C++. This is what abstractions are for. Ignoring detail that is meaningless to the problem domain. Again, it's not really essentially different from the details that C lets you ignore about assembly (which actually includes things like cache coherency. The "1-d plain of memory" abstraction leaks like crazy, performance-wise.)

Wtf? Why sould I believe you. Do you have any proof? Have you tried designing your code better?

Not using shared references when it's easy and guaranteed bug-free is a mindlessly tedious and masochistic restriction. How is this not obvious?

Who says C++ encourages bad design? You?

Lots and lots and lots of people. Try googling it. C++ is probably the most legitimately hated language in existence. Complaints are not by lazy undergraduates, but by people who have used it extensively. A pretty famous example: http://yosefk.com/c++fqa/ Also, Linus Torvalds disallows it on his projects "just to keep the C++ guys out."

>>122
Yes, neglect all of your errors at runtime.

>>121
this.

Seriously just use C. Keep as much as possible in static arrays with small structs. Yeah it's a lot of statements and a lot of typing, but this is how optimization goes. Nobody said optimization was fun or interesting. Very very occasionally it is.

>>123
errors are fewer and easier to debug, provided you know what you're doing. You don't even need an IDE. Generally it's just pretty obvious as long as you have like a week or two of experience.

>>122
I'm not >>116, but just because you can't design things in C++ that are clean doesn't mean everyone has the same problem. I think you have a misconceived definition of "C++ style".

And yes, while GC isn't the cause of bad programming, it does enable a lot more bad programmers to scrape by. I've seen way more bad Java code than C++, where the Java developers were allocating lots of managed objects with huge memory footprints and creating complex object-graphs that would cause painful cache faults during traversal, leaving file handles open, etc. GC makes it easier for you to get by without thinking about how your data is laid out in memory, thus resulting in potentially less performance.

There are plenty of decent C++ programmers who enjoy the language. The problem is that it's always the haters who are the most vocal. This goes for any subject. In the end, your point is nothing more than argumentum ad populum and various other fallacies.

>>124
I'm >>121, I never said to just use C. I actually prefer using C++ to implement the design I mentioned, templates make your life easier, plus you get lambdas/closures which make using the STL algorithms or a algorithmic parallel patterns library like TBB, MPL or Fastflow much easier. The benefit of C++ is that you don't pay for what you don't use in C++, and templates have no overhead over manually hand-expanding the code, and lambdas/closures in C++11/C++0x are just fancy syntactic sugar for functor classes with a member operator() function, which is often less overhead than using a function pointer in C due to the compiler being able to inline the call.

And yes, while GC isn't the cause of bad programming, it does enable a lot more bad programmers to scrape by.

The biggest enabler of bad programmers scraping buy isn't GC but OOP, as popularized by C++ and especially Java. A guy can spend all day writing gettors and settors and design patterns that he doesn't understand and fool himself or others into thinking he's been doing work. It's got nothing to do with GC.

>>128
Yes and no. Yes OOP is the true source of the problems, but GC just compounds the problem when used with overly OO-techniques and abstractions.

This thread is the OOP faggot version of the "gc" thread.

>>129
the worst Java designs could be done easily in C++. In fact, they are usually perpetrated by guys coming from C++.

>>129
The original ``Design Patterns'' book had C++ and Smalltalk in it.

>>132
this is because single-dispatch is kind of flawed. It's not a big deal in Smalltalk though.

>>133
Smalltalk has blocks (and one of the most lightweight and nice syntax for them)

>>134
blocks are not multiple dispatch. They are nice, though.

>>135
Yes, but they add expressiveness. And are nicer than C++'s lambdas.

Sure is ObjC in here.

>>137
Sure is back to the imageboards in here.

>>137
ObjC is single-dispatch also.

fuck, people. come on.

>>113
Also Java's performance is due to the fact that it is its own virtual machine.
No, Java is slow because of its language semantics and horrible type system. For example, there are no user-defined value types, so even to return something simple like a Point2D requires an allocation. Type erasure means every time you pull any object out of a collection, you incur a costly type cast. All methods are virtual by default, so you must dynamically dispatch all calls. These things are slow.

I disagree. Your standards are not correct. Trust me -- I used to think the same thing. But shared references are the way. Good designs use them constantly.

Exhibit A: https://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Smart_Pointers#Smart_Pointers

This is fucking GOOGLE. They probably have a billion lines of C++, and they are saying that shared counted references is bad design. (They recommend shared_ptr<> only go in containers, something that unique_ptr<> will finally make obsolete.)

Please, please don't use shared_ptr<>. Don't do it. Think about the ownership of your objects, for the good of the people who will maintain your code.

Mutable state considered harmful.

>>141
nice

>>141
You just mutated the state of this board's database, harmful faggot.

>>143
/prog/ is updated in a purely functional way, using the Shiichan monad.

ONE WORD: FORCED IMMUTABILITY OF THE STATE

>>140
shared references are bad C++ design. no argument about that.

C++ is bad design though. That is what I'm saying. It's really really simple. Let's take another feature that Lisp invented: real macros.

Technically in C++ it would be possible to build up a string and then compile it and then link your program to it. This would be a terrible idea in C++. But in Lisp you do the equivalent all the time and it's awesome.

>>140
No, Java is slow because of its language semantics and horrible type system.

performance is not about language semantics. It's about the ability to profile and take things native. Optimization is NOT something that should be taken on faith and put in the background and done prematurely. We have known this for decades.

The inability to see that starting most projects in C is *premature optimization* is something only someone who has never written anything other than C/C++ has. It's similar to the inability to see that C++ is flawed, brittle, and idiotic in its design.

>>147
performance is not about language semantics.
Uh actually, in this case it definitely is. Almost any non-trivial program converted from C++ to Java would run much slower, specifically because of Java's semantics.

No amount of optimization can get around the fact that pulling a float out of a Map is horribly, godawful slow in Java. The language semantics mean that the float had to be boxed into a Float and individually allocated from the heap, and it comes out of the Map as an Object (yes, even if you declared it Map<Float>), so the JVM has to verify that its class hierarchy extends/implements Float before you can finally pull the real fucking float out of it. There is no way to optimize it without hand-rolling your own primitive float map, and no way for the JVM to optimize it either.

The syntax of generics and autoboxing hides the semantics of what is actually going on.

>>148
but if Java could be easily embedded in C it would inherit C's performance. This is because bottlenecks are all that matter, and with easy embedding you can find and kill them.

>>149
embedded in C it would inherit the C compiler that happens to compile that C code's performance.

>>149
HIBT? this post is nonsensical. It's already effectively embedded in C because the JVM is written in C/C++. (actually HotSpot is half written in assembly, because fast GC is ridiculously hard to implement.)

If I write all my Python programs in C, is it still the forced indentation of code?

>>151
you are claiming that it is easy to use the JVM as an embedded library in a host C program.

you are retarded.

>>152

This is an important philosophical question that will go unanswered for generations.

ONE WORD: THE FORCED SEMICOLON TERMINATION OF THE CODE THREAD OVER!

Vala

Niggerlang

Ada

ONE WORD: THE FORCED CURLY BRACKETATION OF THE CODE THREAD OVER!

>>159
``But you're supposed to brace your code anyway!''