New language

Runtime optional.
GC optional.
Static typing.
Binary compatibility with C.
Algebraic types.
Lambdas.
Traits.
Safe shared mutable state.

>>1
Terrible!

My name is RMS, and I hate every single one of you. All of you are skinny, beardless no-lifes who spend every second of their day using proprietary software. You are everything bad in the GNU/World. honestly, have any of you ever written a free as in freedom software library? I mean, I guess it's fun encumbering your software with patents, but you take turning computers against the user to a whole new level. This is even worse than proprietary drivers.

Don't be so closed source. Just hit me with your best GNU/Shot. I'm pretty much perfect. I created my own text editor and started the GNU project. What do you code all day, other than insidious methods to control the user and "C-x M-c DRM"? I also danced with a laptop, and rewrote the Unix userland (Just finished a shell script; Shit was SO bash). You are all oppressors of computer users who should release their works under the GNU GPL. Thanks for listening.

GC optional
You'll end up with two programming languages that happen to have the same syntax, guaranteed. Case Study: D.


You'll have to content yourself with C extended with FrozenVoid lambdas.

>>3
/backplate getgoes/

>>4

int * shit = gcalloc(4);
int * notshit = malloc(4);
free(notshit);

>>4
Nope. It's actually a byproduct of the language design. Incidentally, you never have to free.

My language has no GC.
How does it collect garbage?

My language has no dynamic typing.
How does it type?

My language is C/C++ compatible.
How does it work?

>>9
C/C++
Nobody should strive for compatibility with C++'s name mangling.

A good video game allocates everything it needs at startup, then uses a fixed size pool to render each frame. That way video game will have fixed system requirements and could be easily ported to game consoles. No GC needed.

Why there are no Mineraft for Sony PlayStation 3? Because Mineraft is fucking unpredictable in it's resource allocation patterns, it will damage Sony's reputation by making it's console look slow.

>>12
here is a hacked PS3 with Mineraft running:
http://www.youtube.com/watch?v=LT4dxr9JqHM

looks how slow Mineraft runs on such a powerful system! Because it uses GC and Java.

>>13
Not quite, it's because it uses Java's GC. Over a decade has been spent tuning Java's GC for long-running non-interactive programs. It looks good in benchmarks.

That, and I hear Notch wrote some terrible code which exacerbated the problem.

>>14
GC is inherently slow. It's only suitable for ``business apps'' and will always be.

>>15
Sure, it's slow, but is it Abelson slow?

>>15
Nope, retard.

>>15
Instead of posting like a troll you could engage in the discussion of the relative merits of different approaches to GC contrasted against manual memory management if need be.

Did you know that malloc/free isn't O(1)? It's usually something more like O(n), n = total allocated blocks.

>>15

that's why go, the new systems language by plan 9, unix and C inventors has GC lol

>>19
Nobody's going to create a language without GC these days anyway. I'm fond of C, but it's the one language I use with manual memory management. GC in other languages doesn't usually bother me, although once in a while it can be difficult to estimate memory requirements.

>>17-19
same person

GC is shit.

fuck off

>>21
MMM is fucking shit.  Die in a fire.

>>22
child who can't malloc and free

>>23
enjoy your ***((anus*)*(1+*(type*)segmentation_fault))->handler(NULL, NULL, NULL);

>>21-22
stfu both of you

>>22
I can't talk right now, I'm too busy knowing exactly where everything is in memory.
It feels great.

>>26
I can't talk right now, I'm too busy defragmenting my memory, thus enabling me to use all of it.

>>27
I can't tell if you're talking about GC or malloc.

>>28
malloc doesn't allow you to defragment the heap (since the pointers would get all fucked up).  Neither do most GC implementations, because the authors are fucking worse-is-better retards.

>>29
Yes it does. It's true that you can't move allocated data but you can defragment as you free and reallocate. It's a lot faster than compacting and tends to produce a lower memory requirement in long-running programs than compacting does (unless you schedule major collections to run about as often as you return from a call.)

>>30
It's true that you can't move allocated data but you can defragment as you free and reallocate (...) in long-running programs
O(n²).

compacting
O(n), also with less cache misses since defragmenting is done in large contiguous pieces.

Please note that I am against GC implementations that do not allow immediate freeing and/or manually-managed block groups.

>>31
I don't think those numbers are right. For one, the compactor is O(n·m), and it still doesn't solve the major collection scheduling problem. To get guaranteed better memory use, you'll still have collect more often than calling free/malloc.

>>32
For one, the compactor is O(n·m), and it still doesn't solve the major collection scheduling problem. To get guaranteed better memory use, you'll still have collect more often than calling free/malloc.
Well, this discussion isn't about GC vs MMM anymore, but about naïve heap versus everything else; a GC can be (and often is, sadly) implemented on top of a naïve heap, and MMM can be made to use a more refined allocation strategy.  I guess my point really is that if you're going to use a more refined allocation strategy, you might as well slap a GC on top of it as well at almost no cost.

>>33
Well, this discussion isn't about GC vs MMM anymore
Good. That's boring.

I don't really expect GC to beat a modern malloc. I am cool with both automatic and manual methods but I'll take the least sophisticated malloc in common use (probably dlmalloc which appears in msys) or refcounting (with or without cycle detection) over a glacial GC (e.g. Java's) any day.

Today we don't have an issue with speed and we rarely have an issue with memory use. Latency is a big (but not universal) problem in GC'd languages, so I don't mind wasting more time (and space) doing GC as long as the user doesn't notice the difference. I know I pick on Java too much, but traditionally it tends toward explosive memory use, incurring a long-running collection, violating both of these conditions. I hear it's not so bad lately.

>>31
Shalom, hymie^!

>>34
The way Java is constructed inhibits many useful optimizations that could eliminate most GC allocations by converting them into manual allocations.  From Java's design to its implementation, it's turtles all the way down.  For the sake of sanity, I suggest leaving Java out of this discussion.

If you prioritize performance over readability, then what you get is a statically-typed JIT'ed almost-strictly-functional manually-memory-managed language.  Some sort of a Haskell-like monstrosity.

If you prioritize readability over performance, then what you get is a dynamically-typed JIT'ed non-strictly-functional GC'ed (with optional manual memory management) language.

>>35
Fuck off and die, cretin.

>>36
I think Java is a useful example. It's hugely successful yet deeply flawed. It serves to exhibit what people will put up with. I probably don't have to convince you that it's got terrible GC, but I think it has value in framing the discussion, especially since it has prompted me to mention that GC can be a lot better than what many consider to be the state of the art. (Yes, Java actually gets praise for its GC.)

I can't engage on the readability topic because I have no idea how to measure that. We can probably agree on performance metrics, at least within certain givens, but I am sensing a deep disagreement on the readabilty topic already. I find functional code to be reasonably readable. I find C and Python equally readable. The last study I saw on readability was based on badly written Perl code. Even though readability is hugely important to me, I don't think it's something that can be addressed impartially.

If you want to suggest some readability metrics I might be interested in discussing it. They would have to be better than the likes of line count, symbol count, or statement/expression delimiters though.

>>37
http://www.youtube.com/watch?v=DvnrBU4vaGY

>>39
1. Freedom of speech implies that anyone may insult anyone else's religion/race/ethnicity to their heart's content.  Freedom of speech is what allows you to shitpost on /prog/ without fear of imprisonment.  Freedom of speech also implies that anyone's stupid positions may be attacked and disproved by anyone else.
2. The existence of four racist jewish kids doesn't mean anything; discrete events should never dictate societal policy.
3. The video may have been conveniently cut to mask provocations from the guy filming towards the kids.