C++ sucks, Python rules.

In fact, all non-dyanmic languages suck.

[quote author=Banana fanna fo fanna link=topic=14092.msg144162#msg144162 date=1138833788]
C++ sucks, Python rules.

In fact, all non-dyanmic languages suck.
[/quote]

Go Banana fanna fo fanna! 8)

[quote author=Banana fanna fo fanna link=topic=14092.msg144162#msg144162 date=1138833788]
C++ sucks, Python rules.

In fact, all non-dyanmic languages suck.
[/quote]

LOL, i don't know that I agree with that, it really depends on what you can do in the language and how however to an extent I'll go with you ;).

Mark.

Go D!

[quote author=rabbit link=topic=14092.msg144184#msg144184 date=1138838044]
Go D!
[/quote]

FUCK D. D IS FOR THE FRENCH. COMMIE PINKO BASTARDS.

REAL MEN DON'T ABORT BABIES, AND REAL MEN CODE PYTHON.

UNLESS THEY CODE IN ALICE, IN WHICH CASE THEY ARE GIRLIE-MEN.

I'd rather be a pansy than code python! :/

[quote author=Warrior link=topic=14092.msg144233#msg144233 date=1138853185]
I'd rather be a pansy than code python! :/
[/quote]

I thought that coding in Python was what turned them into pansys...

Say the big tough C++ programmers ;). I used Python for 4 years (along with other stuff) and really enjoyed it until recently, it just becomes too limiting. It's also not comparable with C++ for speed yet, though it will prevent a lot of memory leakage in your pants.

Just jesting guys,

Mark.

I'd opt for D or any language with GC if that's the case.
But I usually opt for "It's the programmers fault not the language" and just fix my code,
but that's just me.

[quote author=Warrior link=topic=14092.msg144288#msg144288 date=1138909467]
I'd opt for D or any language with GC if that's the case.
But I usually opt for "It's the programmers fault not the language" and just fix my code,
but that's just me.[/quote]

Worrior, I did NOT say that it was the languages fault – no language is gonna make a bad programmer a good one. I just told you that languages vary in power, and they do, you should probably re-read my posts if you didn't get it :).

Mark.

[quote author=netytan link=topic=14092.msg144270#msg144270 date=1138873458] it just becomes too limiting. It's also not comparable with C++ for speed yet, though it will prevent a lot of memory leakage in your pants.

Just jesting guys,

Mark.
[/quote]

The programmer should prevent the leak, not the language.
Re-read your own posts.

http://www.bebits.com/app/593

[quote author=l)ragon link=topic=14092.msg144310#msg144310 date=1138922114]
http://www.bebits.com/app/593
[/quote]

[quote]Some people even go as far as trying to optimize BrainFuck
code. Here's a small "Hello, World!", by Abhijit Menon-Sen:

>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]>++++++++[<++++>-]
<.>+++++++++++[<+++++>-]<.>++++++++[<+++>-]<.+++.------.--------.[-]>++++++++[
<++++>-]<+.[-]++++++++++.

[/quote]

Good God...

What the HELL is that.

[quote author=Warrior link=topic=14092.msg144313#msg144313 date=1138923093]
What the HELL is that.
[/quote]

"BrainFuck"

Indeed it is.

[quote author=Warrior link=topic=14092.msg144306#msg144306 date=1138920494]
[quote author=netytan link=topic=14092.msg144270#msg144270 date=1138873458] it just becomes too limiting. It's also not comparable with C++ for speed yet, though it will prevent a lot of memory leakage in your pants.

Just jesting guys,

Mark.
[/quote]

The programmer should prevent the leak, not the language.
Re-read your own posts.
[/quote]

Oh what a purist you are Warrior, never in my post did I say that it's the languages fault and not the programmers. Weather or not you like it memory management is much safer & cleaner than managing it yourself – take into account that most none trivial software written in this way contain a number of such bugs.

When I do want to manage my own resources I'll use ASM and get much more control over whats going on in the program, then link this in if that's it's purpose. The best of both worlds :).

You're very welcome to manage the memory yourself and gain nothing from it. If you count longer and more bug riddled programs that run marginally faster for most cases* a gain then thats up to you but having the language do it for you doesn't place blame with the language or the programmer, get over it already.

If anything removing any source of bugs makes it the programmer more responsible for writing bad code, there are fewer excuses :).

I personally would be much happier writing smaller more stable programs which are more or less guaranteed not to leak than writing slightly faster programs at the expense of these things creeping in [as they invariably do].



On a different note BrainFuck fans may be interested in WhiteSpace, a programming language based entirely around the characters we can't see lol. That said it's pretty fun embedding white space programs into others for a laugh. Running the program as language x and it'll do one thing, use white space and it'll do another. There's no real point but it's interesting all the same.

http://compsoc.dur.ac.uk/whitespace/

Here's an example of Hello world written using "whitespace",
http://compsoc.dur.ac.uk/whitespace/hworld.ws

Later,

Mark.

* GC has been around for a very long time (It first emerged in use in the mid 1950's and is under constant research & development. The result is that GC has gotten to the stage where it's efficient, fast and reliable.

You still have to keep track of allocations/references even in a GC language, though.  Especially with things like multithreaded programs or objects with explicit reference counts, you often still end up with the same having to remember to release objects as you would with just deallocating memory in large, non-trivial programs.

Tools for doing things like finding or tracking memory leaks have also come as long way too.  For instance, in Windows, I can use things like umdh and pageheap to quickly discover and investigate memory leaks in a conventional non-GC program.  Due to the deferred deletion / implict deletion nature of GC-based languages, such tools are often much less effective in discovering problems there.

I would submit that GC doesn't really absolve you of having to deal with resource management in many real world cases (non-trivial programs), and a lack of explicit control over resource referencing and deallocation makes non-trivial reference count/leak bugs in GC-based languages more difficult to find than in a traditional non-GC program written in a language like C.

(This has been my observation and experience given debugging problems in both cases.)

Certainly, your experiences may vary, but I don't believe that GC is all that it is cracked up to be given my experiences.

[quote author=Skywing link=topic=14092.msg144340#msg144340 date=1138931833]
You still have to keep track of allocations/references even in a GC language, though.  Especially with things like multithreaded programs or objects with explicit reference counts, you often still end up with the same having to remember to release objects as you would with just deallocating memory in large, non-trivial programs.

Tools for doing things like finding or tracking memory leaks have also come as long way too.  For instance, in Windows, I can use things like umdh and pageheap to quickly discover and investigate memory leaks in a conventional non-GC program.  Due to the deferred deletion / implict deletion nature of GC-based languages, such tools are often much less effective in discovering problems there.

I would submit that GC doesn't really absolve you of having to deal with resource management in many real world cases (non-trivial programs), and a lack of explicit control over resource referencing and deallocation makes non-trivial reference count/leak bugs in GC-based languages more difficult to find than in a traditional non-GC program written in a language like C.

(This has been my observation and experience given debugging problems in both cases.)

Certainly, your experiences may vary, but I don't believe that GC is all that it is cracked up to be given my experiences.
[/quote]

Thats understandable, I personally have never had to worrry about managing resources myself in these a languages. Occasionally I've called 'del' in Python etc. but not for any real reason it just made things clearer at some point.

Reference counting in Obj-C was pretty fun for a while because it's an interesting way to do things – rather than releasing data explicitly you manage a reference counter or mark it for auto release when every object with a  reference is done with it.

I don't know what languages you've used which have GC but none today should make you do that. Letting the GC handel memory is in general much better, you can't miss anything and so don't have go to the hassel of looking for leaks.

Most languages allow you to book when the GC will activate but any relatively decent GC should be sufficient for all but the very most demanding programs, likely all being run on a PC, and then IMO they should be largely written in ASM when speed becomes that much of an issue, or compiled from a dynamic language (if it supports native code compilation) and cleaned there.

Mark.

The only way to program in ASM.