C# useful for AVISynth development?

[Dali Lama]

Hi,

I was wondering if C# ( CSharp ) knowledge would be useful in developing for AVISynth and its plugins. If not, can anyone tell me why?

Thanks,

Dali

[stax76]

Hi,

for best execution speed and little memory usage C++/ASM is used by most people.

[esby]

C# knowledge might be useful,

now avisynth 2.55 is written using C++...

And avisynth 3.0 uses it too.

So, or you can produces compatible filters with the environment you have, and then you can use it, or you cannot.

esby

[kassandro]

Originally posted by esby
C# knowledge might be useful,

now avisynth 2.55 is written using C++...

And avisynth 3.0 uses it too.

Really? The only advantage of C# seems to be that
GUIs can be designed easier and that it is more
sutiable for web applications like Java. Otherwise
it is clearly inferior. C++ compilers simply
generate more efficient code. Now Avisynth has
neither GUI elements nor does it connect to the
internet. Thus it makes absolutely no sense to use
C#. If we would nevertheless use it, then we would
support a proprietary Microsoft standard and would
play into the hands of the evil empire.

[esby]

well I was more talking in a general purpose way.

The more language you know, the better it is...

Now for the purpose of creating an avisynth filter, it is quite useless indeed.

esby

[Dali Lama]

From the webpages I looked at, all of them said that C# was slightly (~5-10%) inferior in terms of performance compared to C++. Also, C# was easier to learn and use. Why do you say its proprietary (how can a language be proprietary?)?

If AVISynth is written in C++, obviously C# won't help much there. But how about writing a plugin with C#. Is it possible, even given the lower performance? I got the notion that C# was compatible with C/C++/J++/VB etc.

Also, does ASM mean assembler? I know ASM is the lowest level programming, very powerful, but hard to learn and use.

Which language would you guys say is really useful, efficient, and powerful for programing today and in the future?

[Richard Berg]

From the webpages I looked at, all of them said that C# was slightly (~5-10%) inferior in terms of performance compared to C++. Also, C# was easier to learn and use. Why do you say its proprietary (how can a language be proprietary?)?
C# can be faster than C++ if the JIT compiler can make profile-guided optimizations. It can also be much slower if you spend all your time boxing/unboxing or thrashing the garbage collector or misusing exceptions. It depends.

A language can be proprietary if it's controlled entirely by one company (e.g. Java). C# is developed by MS but is at least recognized as an ECMA standard with multiple implementations (Mono is getting quite good).

If AVISynth is written in C++, obviously C# won't help much there. But how about writing a plugin with C#. Is it possible, even given the lower performance? I got the notion that C# was compatible with C/C++/J++/VB etc.
Yes, you can write a plugin in C#. The easiest way would be the C interface.

C# is compatible with those languages in very different ways. It supports the C/C++ calling standards but has to marshal objects in & out of the managed heap. It supports VB interop through COM. It supports J# and the other .NET languages natively, i.e. they are executed by the exact same runtime.

Which language would you guys say is really useful, efficient, and powerful for programing today and in the future?
For what purpose? Good arguments could be made for C# or Python or O'CaML or...

Thus it makes absolutely no sense to use
C#.
If I had to write Avisynth 1.0 from scratch today, I'd use C#. Putting ASM functions into their own modules would be annoying, but far less annoying than chasing down memory/cache/destructor/etc. bugs.

[Dali Lama]

Originally posted by Richard Berg

For what purpose? Good arguments could be made for C# or Python or O'CaML or...

Good question. I'd like to be able to make programs that would be useful in the medical, pharmaceutical, or biotech fields...but at the same time it wouldn't hurt to make an AVISynth plugin.

I know those are broad fields. But I imagine I might want to simulate human behaviors and make models of disease, prevention, intervention, etc.

After reading some introductions of programming books, it seems like C++ or C# might be the way to go for me. Although, I've never heard of CaML.

[kassandro]

Originally posted by Dali Lama
From the webpages I looked at, all of them said that C# was slightly (~5-10%) inferior in terms of performance compared to C++. Also, C# was easier to learn and use. Why do you say its proprietary (how can a language be proprietary?)?

The performance penalty of C# depends heavily on the application. If it is very simple, there won't be a real difference. If it is very pointer intensive like Avisynth the performance penalty can be huge. Moreover, if it frequently allocates/deallocates memory languages like C# or Java may be even unusable, because in these languages you can't deallocate objects. This is done by a garbage collection instead. Garbage collection is probably the worst idea in these languages. The basic sentence in C++ is: you must be very careful about memory. The basic sentence of Java/C# is: don't care about memory, I (the garbage collection) do it for you. Clearly that makes languages like Java or C# much easier to learn, but if your first programming language is a lousy one like Java or C#, you are lost forever. You can really learn anymore a "precise" language like C++. dvb.matt, the programmer, which created the outstanding ProjectX, is an excellent example. Obviously, his first language was Java, whence ProjectX was designed in Java. Consequently, this application swallows resources like crazy (a 256 MB PC is hardly usable with this program). Java is really not usable for such an application. If he would have started with C++ he could have made at least the command line version of projectX with the same ease and we wouldn't get punished by Java every day. I recommend to any beginner to start with C/C++. If she/he is unable to overcome the "pointer barrier" and cannot become pointer wizard, she/he then should learn Java. Java is essentially a subset of C++ with an extensive platform independent library. C# is Microsoft's answer to Java. There are two advantages of C#. Firstly, it is more efficient than Java, because one can creat truely binary executables, and secondly GUIs created with C# look much better than those created with Java, which is not surprising because Java unlike C# is platform independent. However, you can compile many java programs with gcj, the GNU java compiler, which uses the excellent backend of the GNU C compiler. Unfortunately, the library support for gcj is not sufficient to compile sophisticated GUI applications, but that will probably change over time. I say that C# is proprietary, because Microsoft is the only source for development tools. If Microsoft abandons it, C# is dead. Since its competitor is well established and probably will become open source and most programmers do not want to put themselves at the mercy of a bully like Microsoft, C# will probably die one fine day.


Also, does ASM mean assembler? I know ASM is the lowest level programming, very powerful, but hard to learn and use.

Yes, ASM means assembler. Usually assembler doesn't make much sense. A C/C++ Compiler like that from Intel may even often generate faster cade, because Intel knows more about instructions scheduling for their various CPUs than anybody else. Avisynth is a notable exception, because only with assembler you can really utilise the MMX/3DNOW/SSE/SSE2/SSE3 instruction units of your cpu and these instruction units can have an enormous performance impact, because you can process up to 16 pixels simultaneously.


Which language would you guys say is really useful, efficient, and powerful for programing today and in the future?
If you really want to become a serious hacker, C++ is the only choice.

Originally posted by Richard Berg

If I had to write Avisynth 1.0 from scratch today, I'd use C#. Putting ASM functions into their own modules would be annoying, but far less annoying than chasing down memory/cache/destructor/etc. bugs.
Well, if you have 100GB of RAM and a 10 GHZ cpu, this would probably be fine. If you don't, then you simply must thoroughly care about memory.

[HeadlessCow]

Originally posted by kassandro Moreover, if it frequently allocates/deallocates memory languages like C# or Java may be even unusable, because in these languages you can't deallocate objects. This is done by a garbage collection instead. Garbage collection is probably the worst idea in these languages. The basic sentence in C++ is: you must be very careful about memory. The basic sentence of Java/C# is: don't care about memory, I (the garbage collection) do it for you. Clearly that makes languages like Java or C# much easier to learn, but if your first programming language is a lousy one like Java or C#, you are lost forever. You can really learn anymore a "precise" language like C++.


If that's what you learned about Java, then you had a horrible teacher. Garbage Collection helps with exactly one aspect of memory handling: Deallocation. If you think that means that you don't have to worry about constant allocation of objects you're sorely mistaken.

Garbage Collection allows you to avoid errors caused by the complicated tracking of objects that you are forced to do in order to correctly free memory at the right time in languages like C++. I'd, jokingly, suggest that the average Java programmer is just as competent at this as the average C++ programmer :D

I say that C# is proprietary, because Microsoft is the only source for development tools. If Microsoft abandons it, C# is dead. Since its competitor is well established and probably will become open source and most programmers do not want to put themselves at the mercy of a bully like Microsoft, C# will probably die one fine day.


If MS abandons it, C# may very well die...but that ignores both the Rotor (MS shared source implementation of .Net for BSD) and Mono (a GNU implementation) as well as the (supposedly) decent IDEs like SharpDevelop. Since it's also been ratified by ECMA, even MS can't make changes to the base language without approval.


If you really want to become a serious hacker, C++ is the only choice.


Language choice changes over time, 20 years ago you could have been safe hacking on Lisp and FORTRAN :p

The most useful language to learn can't be answered with a single language. Become good at as many as you can and study the way they work and how computers work. Learning new languages is easy for people who are truly hackers.


Well, if you have 100GB of RAM and a 10 GHZ cpu, this would probably be fine. If you don't, then you simply must thoroughly care about memory.


Did a garbage collector run over your pet? Did a JIT compiler steal your lunch money? Just because you can't handle programming in a managed language doesn't mean that everyone sucks at it.

[Leak]

Originally posted by HeadlessCow
Did a garbage collector run over your pet? Did a JIT compiler steal your lunch money?

My thoughts exactly...

Moreover, AviSynth as an example would be a program where a garbage collector hardly makes a dent in the programs performance, as most of the objects are rather large (frames, that is), most other stuff is allocated once at initialization time and using a simple pool mechanism allows one to re-use frames, thus avoiding constant reallocation of frames - the cache currently implemented in AviSynth roughly does the same.

Of course, garbage collection can be slow if it's done on a huge amount of tiny objects (i.e. a node datastructure or something similar), but even then there are incremental garbage collectors that clean up the heap in small steps over time, which is hardly noticeable...

Anecdotal evidence: in one larger application I wrote (a text editor with inline elements, implemented as a Swing component), the debug info for the garbage collector of Java 1.5 logged the incremental collection runs as taking below 5 ms, while a full collection took 20-30 ms every now and then, while working on a really large file *and* constantly redrawing the screen.

(The only time it got dog slow was on a system where the windows graphics driver was b0rked, so Java2D had to emulate off-screen drawing - but what to do? The same machine running Knoppix worked quite normal...)

Maybe garbage collection isn't such a big deal with programs like AviSynth that don't have really complex data structures, but there's a lot of situations you can get into where it's almost impossible to decide when to delete or free() an object - which is where a garbage collector really helps.

I'm not saying you can't produce memory leaks with a garbage collector (filling hashtables without throwing away things, for instance) - it just saves you from a world of hurt when you know you can throw away a reference, but can't know whether you can safely deallocate the object.

Also, a compacting or copying garbage collector fixes internal fragmentation while it's working, which also tends to be a problem when you're frequently allocating/deallocating objects of varying sizes.

np: Markus Guentner - Damit Du Endlich Weisst, ... (Pop Ambient 2004)

[kassandro]

Sorry, I didn't want to start a language flame war and this is certainly not the right place for it.

Originally posted by HeadlessCow
If that's what you learned about Java, then you had a horrible teacher.

I have to confess that my Java knowledge is only very surficial and I have never done any serious programming with it. The same applies to C#.


Garbage Collection helps with exactly one aspect of memory handling: Deallocation. If you think that means that you don't have to worry about constant allocation of objects you're sorely mistaken.

Of course garbage collection never allocates memory for you. You simply allocate memory by creating objects in these languages. In anti pointer languages like Java (that is the reason, why I will probably never get comfortable with them) garbage collection should do more than deallocating objects. Because there is only one reference to a memory chunk in these languages, garbage collection could very well do heap defragmentation, as mentioned be Leak. Actually this is the only advantage of anti pointer languages.


Garbage Collection allows you to avoid errors caused by the complicated tracking of objects that you are forced to do in order to correctly free memory at the right time in languages like C++.

In most cases, the time of deallocation is very obvious and it is ideally done by a destructor. There are some exceptional cases, though, when memory objects are used in many instances. However, then you use simply use smart pointers in C++ as it is done, for instance, in avisynth.h. Moreover, if a smart pointer generates only overhead, you can always change to a "lean" pointer without using a cast.


Did a garbage collector run over your pet? Did a JIT compiler steal your lunch money?
Something similar: Sometimes when I use ProjectX to demux some DVB transport streams, the mpeg2 decoder of the DVB program ALT-DVB gets jerky, although the mpeg2 decoder mostly uses the GPU and ProjectX cpu usage is only about 40-50%. Actually on a system with "only" 256 MB projectX it virtually blocks the PC. It is at these occasions, when I curse these resource vasting languages.

Originally posted by Leak

Also, a compacting or copying garbage collector fixes internal fragmentation while it's working, which also tends to be a problem when you're frequently allocating/deallocating objects of varying sizes.

Actually this is the only good reason for a garbage collection, but then programming is a pain. I would like to have full control over it
and call the heap defragmentation, when I want it. This would leave somewhat more programming freedom than with heap defragmentation by a background thread.

[HeadlessCow]

Originally posted by kassandro
Sorry, I didn't want to start a language flame war and this is certainly not the right place for it.

Agreed, but we might as well all learn something here :)


I have to confess that my Java knowledge is only very surficial and I have never done any serious programming with it. The same applies to C#.

Well, there's plenty of people that do programming in Java (even relatively serious programming) that still have no idea how it works. So you're almost definately in the majority :p

My experience with C# is also lacking, so for examples I'll refer to Java, but most of this can be applied in general to any GCed language.


Of course garbage collection never allocates memory for you. You simply allocate memory by creating objects in these languages. In anti pointer languages like Java (that is the reason, why I will probably never get comfortable with them) garbage collection should do more than deallocating objects. Because there is only one reference to a memory chunk in these languages, garbage collection could very well do heap defragmentation, as mentioned be Leak. Actually this is the only advantage of anti pointer languages.


What I meant was that garbage collection didn't free you from having to understand what the effect is when you start declaring objects. You still need to worry about the fact that everything you allocate takes up memory even though Java doesn't force you to think about it like C/C++ does when you fail to call free on something. Those languages force you to constantly think about reclaiming memory which in turn makes it very obvious when you're allocating from the heap. Java doesn't make you worry about the reclaiming, so it's easier (and more common) for people to just fail to think about the fact that they're allocating large amounts of memory.


In most cases, the time of deallocation is very obvious and it is ideally done by a destructor. There are some exceptional cases, though, when memory objects are used in many instances. However, then you use simply use smart pointers in C++ as it is done, for instance, in avisynth.h. Moreover, if a smart pointer generates only overhead, you can always change to a "lean" pointer without using a cast.


"Smart" pointers in C++ implement an extremely naive, flawed and inefficient version of garbage collection (just make a circular linked list and you can see the flaws of reference counting algorithms). That's not to say that they don't solve the problem they set out to solve (prevent double frees), but Java's garbage collection algorithms (and I assume C#'s) use significantly more complex and better performing ways of dealing with this.


Something similar: Sometimes when I use ProjectX to demux some DVB transport streams, the mpeg2 decoder of the DVB program ALT-DVB gets jerky, although the mpeg2 decoder mostly uses the GPU and ProjectX cpu usage is only about 40-50%. Actually on a system with "only" 256 MB projectX it virtually blocks the PC. It is at these occasions, when I curse these resource vasting languages.


The fact that ProjectX can cause this much of a problem in such a relatively large amount of memory points toward mistakes in the programming rather than issues in the runtime. In fact it sounds very similar to issues that I just encountered (and solved) at work. We were parsing a large (150meg) file and then committing it to the database. The original, naive code allocated memory like crazy while parsing and outputting it and our reworked code was able to execute at several times the original speed and allocating millions less objects which cut us down to a single GC after the parsing rather than one every 10 seconds with the original code.

Java is partly to blame here because the naive code for reading/parsing files is extremely obvious to implement and, as long as you deal with small files, it is a relatively high performing solution. Luckily profiling tools for Java make it easy to find these issues and solve them.

than
Actually this is the only good reason for a garbage collection, but then programming is a pain. I would like to have full control over it
and call the heap defragmentation, when I want it. This would leave somewhat more programming freedom with heap defragmentation by a background thread.

Why would this make programming a pain? The heap defragmentation is fully transparent to the user and for a copy collector like Java uses for most of its garbage collection it is also relatively easy to write. Mark/sweep/compact collectors are complicated to implement, but a developer isn't required to implement one nor is it normally required that you even know that such a collector is being used.

Java also supplies several other non-default collectors that allow everything from parallel collecting (for multiple CPU machines) to a non-blocking (for almost all of its execution) collector that allows the program to continue running during GC steps that would previously have caused the program execution to stop.

Your idea of executing heap defragmentation on a background thread isn't possible though. First, you can't move an object around the heap without stopping the execution of any threads that might access it since you're changing its address in memory. Second, any objects that hold a reference to it, and in C/C++ this could be anything that has an int, need to be updated to point to the new address of the object. Java solves these issues partially by locking the heap, thus stopping all other threads, for as short a time as possible during collection and, since it doesn't have user accessible pointer semantics, it is also able to find and update all external references to the objects that have been moved.

Of course, all this great software is wasted if people aren't careful with what they're doing :)

[HeadlessCow]

Ok...so I grabbed the ProjectX source and did a quick (after I got used to NetBeans) little bit of profiling to see what sort of obvious bottlenecks I could find. I grabbed a small music video vob (mpeg2 + LPCM) that I had laying around and demuxed it.

Look at the value listed for Objects Allocated.
http://headlesscow.com/projectx/profiling-orig.png

Byte arrays were being used about 26 million times more than any other object in the system. And almost all of the uses came from the same method. So I says to myself "Self, this is crap." and I take a look at the method.

private void byteOrder(byte data[], int off, int len)
{
byte value[] = new byte[len];
System.arraycopy(data, off, value, 0, len);

for (int a=0; a<len; a++)
data[off+a] = value[len-1-a];

value = null;
}

Pretty innocent looking, right? Create a new byte array, copy the old array into the new and then reverse it back into the original. It's a little odd that it directly manipulates the passed in byte array instead of just returning the reversed array, but whatever.

That declaration of value happens everytime this method is called though, which is apparently a lot. So I make a couple of little changes so that it's a little bit more intelligent.

First I add a static temp array so that a new one doesn't need to be allocated every method call.

public static byte[] swapTemp = null;

Then I fix the method to be intelligent enough to use the new temp array and resize it (larger only) as needed. The method uses the exact same

private void byteOrder(byte data[], int off, int len)
{
if (swapTemp == null || swapTemp.length < len) {
swapTemp = new byte[len];
}

System.arraycopy(data, off, swapTemp, 0, len);

for (int a=0; a<len; a++) {
data[off+a] = swapTemp[len-1-a];
}

}

I also noticed that the author had programmed in a LOT of calls to System.gc() to invoke the garbage collector. This is *BAD* because rather than doing small garbage collections as needed and a full collection only when absolutely required to, the JVM now is doing full collections even when there's no reason to and these can take a reasonably large amount of time.

I rebuilt the app and demuxed the same video again...and it's much faster this time (I didn't test the original code while not running in the debugger, so you may not see the same kind of speed gain that I did, but it should be faster nonetheless). Looking at my handy profiling results I see much nicer data. Only ~26% of the objects
instead of 99%. (I cut out a large section of the allocations in the middle of this list)

http://headlesscow.com/projectx/profiling-new.png
http://headlesscow.com/projectx/profiling-new2.png

And look, those 26.7 million byte arrays that were previously allocated have been collapsed down to a single allocation. Good job me! But just to check that I didn't break anything...

C:\media>diff "Koda Kumi - Hands.m2v" "Koda Kumi - Hands.m2v.orig"

C:\media>diff "Koda Kumi - Hands.wav" "Koda Kumi - Hands.wav.orig"

C:\media>

Yay!

Grab a copy from here (http://headlesscow.com/projectx/ProjectX.jar) (right-click, save as... my server is sending it as plain-text right now) and check if it helps with the issues you had with it.

There's plenty more work that could be done on the code, and maybe I'll start to whack at some of the more obviously deficient elements, but the codebase is so large and unwieldy (The main class, X.java, is about 18000 lines of loosely related code) that NetBeans trips over itself trying to edit it. It's a shame since the profiler in NetBeans is quite nice and free (We use OptimizeIt on Solaris at work) though I like Eclipse a lot more as an IDE :)

[kassandro]

Wow, I have tested your modified ProjectX and it really blasts through the transport streams. Moreover I am also getting no more reminded that ProjectX is running while watching TV.
I have forwarded your contribution to the ProjectX
support forum (http://forum.dvbtechnics.info/showthread.php?t=1646) (it is a primarily a german forum, but english contributions are wellcomed too).
It is nice to see, that from some stupid like a language flame war something extremely useful can emerge.

[vcmohan]

This is too high brow for me. However I am wondering whether after all this discussion about relative merits of programming in C++, c# and java whether Avisynth switches over to java! Have I to learn more languages?

[Leak]

Originally posted by HeadlessCow
First I add a static temp array so that a new one doesn't need to be allocated every method call.

public static byte[] swapTemp = null;

Then I fix the method to be intelligent enough to use the new temp array and resize it (larger only) as needed.

Ummm... this might only be a nitpick, but why allocate an array at all and not just do it in-place?

You can use a loop that goes to half the length of the array and swap the first and last elements, the second and next-to-last one etc. until you hit the middle element - that should be even faster and use just a single temp-byte on the heap.

[kassandro]

Originally posted by Leak
Ummm... this might only be a nitpick, but why allocate an array at all and not just do it in-place?

You can use a loop that goes to half the length of the array and swap the first and last elements, the second and next-to-last one etc. until you hit the middle element - that should be even faster and use just a single temp-byte on the heap.
Very nice observation, Leak.

[HeadlessCow]

Yeah, that's a better way but I wanted to show the difference caused by only adjusting the allocation strategy rather than actually changing the algorithm that the code was using :)

[HeadlessCow]

Originally posted by vcmohan
This is too high brow for me. However I am wondering whether after all this discussion about relative merits of programming in C++, c# and java whether Avisynth switches over to java! Have I to learn more languages?

Well, I'm certainly not going to port it ;) Java has other gotchas though that make it less than ideal. The lack of unsigned bytes/ints would probably cause a bunch of problems :-/

[kassandro]

@HeadlessCow:
The folks over in the german forum critisise that LPCM audio is not typical. DVB streams usually have mp2 audio and sometimes also ac3 audio. For your tests you should choose a VOB file with mp2 audio.

[HeadlessCow]

Sure, I can check those out as well. I'll just have to find a vob that has them. Oddly enough both the vobs I had on my computer and the DVD I had sitting on my desk used LPCM audio :)

[HeadlessCow]

I ripped a DVD that had AC3 audio and found an HDTV cap online that had mp2 audio and things look a lot better than the LPCM code :) There's nothing that stands out as particularly horrible like the 26.7 million byte arrays. If you tried on a file with one of those audio tracks and saw an improvement it was strictly due to me taking out all the calls to System.gc(). I'll try to continue looking for performance improvements that I can make, but I have a real job during the week so it'll basically be in my spare time on weekends :)

It looks like there are places where methods allocate the same array repeatedly due to looping when they could probably just reuse an already existing array for some benefit.

[jstelly]

I love C#, it's a great language for a lot of things, but from my experience there's very little value-add of converting an existing project to a new language unless the current language is causing serious problems that the new language will fix.

I think it would probably be pretty easy to just write a plugin for AviSynth using managed C++ that creates a managed interface and can load .NET assemblies. So the script would load the managed C++ plugin, which would expose a function that lets you load a .NET Assembly that conforms to this managed interface. In fact, adding something like that to the core of AviSynth would probably be relatively simple and wouldn't break existing plugins.

How often the managed interface would get used is anyone's guess, but it could be nice to be able to quickly put together a plugin to try some new effect out.

[geoffwa]

...people who write garbage.

[esby]

Garbage collection is for...
...people who write garbage.

That sounds like a great argument.
seriously.
If you don't see the interest of garbage collectors, Fine.
But Don't mock or insult in any way people who are using it.
You are not them, you don't have their needs.
There are always several ways to create and maintain codes.
And for the later part, the more people involved, the better it can be with garbage collectors and shared pointer list, as I include them in the garbage collector category, as you don't have to check that other people forgot to do correctly their job.

Now the original thread is not to flame but to discuss seriously.

esby

[sh0dan]

Originally posted by geoffwa
...people who write garbage.
This is as close to flamebait you'll ever get in this forum. Consider this a warning.

[shevegen]

"The most useful language to learn can't be answered with a single language. "

That is true, but I recommend everyone to learn either C or C++ before taking up on one of the scriptining languages - the easier they make it for you to write code (that is a good thing, mind you!), the less you want to learn more "real" languages like C or C++.

If I would have a head start again, I would start to learn C if the choices are between C CPP Java and C#. :)

[HeadlessCow]

I learned on Pascal...which I think is a pretty decent place to start. Sure, it's not generally useful, but until you get to pretty advanced stuff it doesn't really matter what language you're learning on. Any of them make it easier to pick up any other within a broad genre. Like, LISP isn't gonna help you much with C and neither will help you much with PROLOG, but any of the basic imperative languages will make it easy to learn most of the stuff you'll be exposed to, so you might as well start on the easiest and get into learning algorithms as quickly as you can. A 5% speed boost from C isn't useful when changing your algorithm to something that's not O(n^2) would have made it exponentially more efficient.

Just don't pick Perl :p

[stax76]

Garbage collection is for...
...people who write garbage.


reminds me of a quote by Joel Spolsky (http://www.joelonsoftware.com/) found on Mono (http://www.go-mono.com/monologue/) blog:


But mostly because I'm a pedantic windbag who can't resist the opportunity to teach a little lesson to the younguns who think that a compiler has to generate machine code.


I highly recommend his blog, especially to the younguns...