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?

>>77
itt people think memory management is hard

>>81
Get out.

>>82
NO U

In all seriousness, are you one of these idiots who think it's impossible to write correct, scalable code that manually manages memory? Do you think the Linux kernel or the Unreal engine fell out of the sky?

>>83
It's possible, just like it's possible to write correct, scalable code in pure assembly.
In all seriousness, are you one of those idiots who think they have control over machine just by manually managing memory?

>>58
And I think manual memory management is about as silly as manual CPU register management. (Seriously, demonstrate that there is an essential difference, please.)
That's downright silly. Using automatic register allocation does not cause periodic stalling of your program while a 'register collector' is run. A garbage collection pause, on the other hand, can severely impact the user experience, and tweaking it to make it less noticeable has significant impact on the resource consumption of the application. There's a reason why no modern game engine is written in a garbage collected language.

Shared references, as a general technique, is also insanely useful. It's not just that having to keep track of "owners" is tedious, it also limits your design considerably.
Failure. You *should* be tracking the ownership of each object as part of the design of your program. Many objects actually need to have explicit ownership because they need to be cleaned up: file handles, network sockets, sql statements and cursors, etc. It's much better to have a good idea of the ownership of all objects.

I tend to write ad-hoc reference counting and GC pretty regularly while writing C++.
You're doing it wrong. So very, very wrong. The resulting code is likely slower than using a GC; if you're too incompetent to manually manage your memory, then use a GC language for fuck's sake, but don't pretend like this is a good thing. I hope I never have to maintain your code. (For the record, I think shared_ptr<> is cancer and you are cancer for using it. scoped_ptr<> and unique_ptr<>, on the other hand, are wonderful.)

>>65
What are you trying to predict? If you know your machine has 4gb available, predictability isn't important.
Dude, it's not about the total memory usage. A big part of it is being able to control the layout of your memory so you get consistent and predictable cache performance. An equally important part is predicting that you won't get a goddamn GC pause in some innocuous piece of code (and before you say malloc is unpredictable, yeah we know it is, which is why manual memory management allows me to write performance-critical sections without fucking allocating memory.)

>>84
In all seriousness, are you one of those idiots who think they have control over machine just by manually managing memory?
No; I think I have control over when a GC stall is going to occur. Never. :) I also have a much better idea of the *actual* resources that will be consumed by my application, and that it won't consume an order of magnitude more resources than it actually needs in order to run at a pace that the user will enjoy.

>>86
:)
*actual*
Oh, now I understand.

>>80
Mind an example of this language?

>>88
Anything with proper anonymous functions.

>>89
Ah, ok, then that's IHBT

>>90
Objects are poor men's closures.

>>91
[i]ONE WORD THE FORCED CLOSURE OF THE LAMBDAS[/i]

D
/Thread

Go!


main .. {
  include "sys:go/io.gof".
  include "sys:go/stdlib.gof".

  main() ->
      drink(99);
      stdout.outLine("Time to buy some more beer...").

  drink(0) -> {}.
  drink(i) -> stdout.outLine(
       bottles(i) <> " on the wall,\n" <>
       bottles(i) <> ".\n" <>
       "take one down, pass it around,\n" <>
       bottles(i) <> " on the wall.\n");
      drink(i-1).

  bottles(0) => "no bottles of beer".
  bottles(1) => "1 bottle of beer".
  bottles(i) => i^0 <> " bottles of beer".
}

>>94
ONE WORD THE FORCED CAPITALIZATION OF EXPORTED SYMBOLS THREAD OVER

>>88
Any language with real first-class closures. JavaScript is a good example of this: the way it does OO is basically glorified closures. The best example is of course Lisp, but I wasn't about to bust that one out first, since you've probably already stopped reading this post by now.

>>96
Lisp
stopped reading after that

>>55
I mean Java does not suck that much
HAHAHAHA OH BOY

Working without GC is easy, at least in C++.

Most of the time you can just use stack. When you actually need heap allocation, most of the time you can wrap it in class and release the memory in destructor. That way you won't get  memory leaks.

Sometimes you don't have to wrap the memory in class yourself, but you can use auto_ptr (deprecated) or unique_ptr. That is just as effective as manually using new and delete, but is exception safe and is easier to manage (also you can't forget to free memory). shared_ptr is also ok in some cases, but has some overhead and you can avoid using that by just designing your code better.

However, you have to keep the releasing of the memory in mind when you design your program. If you cannot do that, you are a bad programmer, and should just use GC language.

It really isn't that hard. Only thing you have to remember, is that whenever you use new, you have to also have some mechanism to free the memory.

I agree GC is ok for some cases, for example in scripting languages, where you don't need a good performance. However, many applications that have be coded with GC'd language (like C# or Java) are slow. I'm not sure if it's because they are not native code or because of GC? Some people claim that JIT should make the byte code as fast as native code, so that leaves the GC to be blamed. Or maybe it's because the "premature optimization is the root of all evil" claim that makes these software slow? I don't think so, because software written is C is almost always fast, and software written in C# and Java is almost always slow.

Or maybe it's because coders that need GC are bad programmers and produce slow code?

>>99
You do really think that for most applications, storage that lasts just for the dynamic extent of a procedure will be enough? Suddently, applications have to maintain no state?
However, many applications that have be coded with GC'd language (like C# or Java) are slow. I'm not sure if it's because they are not native code or because of GC?
I don't know for .NET, but the JVM is slow because it has to load all the bloat first, and the JIT has to warm up and find the hotspots in your program.
Some people claim that JIT should make the byte code as fast as native code, so that leaves the GC to be blamed.
A JIT emits ``native code'', you damned moron. And the GC doesn't run perpetually, and surely not at the startup.
Or maybe it's because the "premature optimization is the root of all evil" claim that makes these software slow?
Explain why not assembly, if premature optimization is not evil.

Also, you keep saying ``GCed language'', but I don't see the word ``GC'' in Java's spec, or Lisp's, Scheme's, ....

>>100
Also, you keep saying ``GCed language'', but I don't see the word ``GC'' in Java's spec, or Lisp's, Scheme's, ....
Your estimated IQ dropped at least 50 points after I read your last phrase.

>>97
Don't be a faggot.  He's talking about Lisp's indisputably sane semantics.  He's not even advocating it or acting elitist towards users of other languages.  I say, you are doing a great injustice to >>96-san.

>>100
Classic sheltered GC defender, falling back on insults and personal attacks instead of coming up with good arguments.

I don't know for .NET, but the JVM is slow because it has to load all the bloat first
wat

I don't get all this JIT discussion. It has nothing to do with GC. And yes, Java is slow largely because of GC. 98% of the software engineering investment in the JVM has been for the GC.

>>103
Classic sheltered manual memory management defender, falling back on idiocy and irrelevant details instead of coming up with good arguments.

THIS IS A MESSAGE FROM THE SUSSIX DEV TEAM

If ``premature optimization is the root of all evil'' will intentionally writing slow code make our programs inherently good?


THIS HAS BEEN A MESSAGE FROM THE SUSSIX DEV TEAM

You guys are forgetting something really important.

GO KILL YOURSELVES

>>103
I don't get all this JIT discussion.
You mentioned the JIT.
>>101
Your estimated IQ dropped at least 50 points after I read your last phrase.
You can do automatic memory management without a GC. And the specs still don't mention a GC anywhere.

>>85
Using automatic register allocation does not cause periodic stalling of your program while a 'register collector' is run.

automatic register management being efficient is a relatively new invention.

A garbage collection pause, on the other hand, can severely impact the user experience, and tweaking it to make it less noticeable has significant impact on the resource consumption of the application.

this depends on the garbage collection algorithm. I agree that Java's is unsuitable. I've never seen such bad "hiccups" in other implementations, except occasionally with C#.

There's a reason why no modern game engine is written in a garbage collected language.

XNA. Love2d. Moai. Also, EVERY modern game engine has at least 1 scripting language for doing non-intensive things. I seriously give it 5-10 years until you start seeing ground up game engines written in something like LuaJIT.

>you *should* be tracking the ownership of each object as part of the design of your program. Many objects actually need to have explicit ownership because they need to be cleaned up: file handles, network sockets, sql statements and cursors, etc. It's much better to have a good idea of the ownership of all objects.

dynamic-wind (or whatever, it's trivial to implement.) Closures win again. In CL you can even do it with a macro like C# essentially does with its "using" statement. Sorry, but dealing with that kind of stuff is easy with lambdas, and far more explicit than overloading the semantics of "}" the way C++ does. Tying this stuff to the lifetime of an object is a hack to get syntactic sugar, just like everything else in C++.

I remember the day that I realized that the C stack was a really limited automatic memory manager. It's probably in the top 20 enlightening moments.

>>105
No. The idea is that you write code that is correct. You will then profile that code to get some data about where you need to optimise.

>>107
You mentioned the JIT.
Newsflash: there are more than two of us in this thread. *gasp*

>>108
automatic register management being efficient is a relatively new invention.
And automatic memory management is a relatively fictional invention.

I'm not sure what your point is either. People still wrote a lot of stuff in assembly until compilers became efficient. It's 2011 and garbage collectors are still grossly inefficient, so doesn't it make sense to skip them for non-trivial applications? We've seen how slow and unresponsive Java apps like Eclipse can be. They're awful. Besides, manually managing memory is not nearly as difficult or time-consuming as handcoding assembly; in fact memory management comes naturally in a well-designed application.

modern
XNA. Love2d. Moai.
I lol'd

>>92
ONE WORD THE FORCED FAILURE OF THE BBCODE

>>111
there are lots of non-trivial applications that aren't CPU bound or don't need to be performant anyway. For instance, anything that runs on a server and/or deals with a database.

Also Java's performance is due to the fact that it is its own virtual machine. Nobody embeds Java, so there's no way to optimize it by going native.

I think this needs to be said over and over: something is optimized if and only if you can optimize it later after profiling. This is why I consider embedded languages to be faster than giant VM languages. (Please don't use Java as a golden standard of anything because it's not. Nobody here is arguing for Java.)

in fact memory management comes naturally in a well-designed application.

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. But good C++ designs don't. Get it? It's very simple. C++ encourages BAD design, not good.

>>111
And automatic memory management is a relatively fictional invention.

He still thinks managing memory is an essential and unsolved problem worthy of premature attention and man-hours before profiling!
laughinggirls.jpg

>>114
Go back t-ah, fuck it, you're right.

>>113
there are lots of non-trivial applications that aren't CPU bound or don't need to be performant anyway. For instance, anything that runs on a server and/or deals with a database.
Most software that deals with database are boring and trivial enterprise software.

Also Java's performance is due to the fact that it is its own virtual machine.
No, it's because the GC is slow and the GC encourages programmers to code badly without understanding what affects to the performance. So there are at least two reasons why GC makes Java slow.

But shared references are the way. Good designs use them constantly.
Wtf? Why sould I believe you. Do you have any proof? Have you tried designing your code better?

It's very simple. C++ encourages BAD design, not good.
Not very simple at all. Who says C++ encourages bad design? You? Citation needed!

>>116
This.

I don't understand why is reference counting evil.

I'm currently developing a Seihou ripoff in C (not sepples) and I have two basic projectiles types:
- The entity, which contains the state of a bullet and a reference to a function used by a very simplistic virtual machine in order to compute the state from the time the entity has lived;
- The polyline, which is a linked list of pointers to entities.
A polyline is rendered as a polyline connecting the entities, and an entity is simply a sprite.

I'm using reference counting and an ENTITY_INVALID flag in order to permit the removal of an entity while polylines or VM threads still refer to it. When there's a hole in the polyline, I split it in two, and I kill threads referring to invalid entities. Is it bad design?

Also, but that is completely unrelated to the subject, the VM is currently executing an extremely shitty bytecode produced by NASM macros abuse and I'm thinking of replacing it with a Lisp-like interpreter.

>>116
Java isn't slow because the GC is slow. You should know this.

>>118
Reference counting has some things people need to be aware of. If you don't use it correctly, you will pay the price.

To correctly do reference counting in C or C++, you need to make the release operation thread-safe, so that if two threads hold a reference to the same object, if the threads release the object at around the same time, it's possible you'll get a double-free unless you protect the reference count.

Generally, this is done using native CPU specific atomic compare-and-swap instructions. These instructions lock cache-lines or even the memory bus. On x86/x86-64, for example, a compare-and-swap takes around 150-200 cycles (where as say a simple dec and jnz might would just be a couple of cycles granted that the reference count is in the CPU cache and the branch predictor doesn't fault.

There's overhead. Therefore you should avoid lots of fine-grained reference counted objects. You don't need to use reference counting for everything. Use reference counting only where you need to, and on heavier-grained objects which explicitly manage smaller-grained objects. That way you can setup strong ownership rules: when the heavier-grained object goes out of scope or is released, it will cleanup and free all of the fine-grained objects it owns, no expensive reference count release operations.

There are also different ways of implementing reference counting: intrusive and external. Intrusive is less expensive in practice, less memory fragmentation, single malloc and free per object, but you can't have weak references which are useful for implementing cycles. External reference counting is more usable, but often allocates the reference count in it's own block of memory, although there are ways to make it intrusive (see C++'s std::make_shared function).