I believe the only way to hinder learning of one language is if you start with a higher level language and go to a lower level language. There is always a significant increase in requisite complexity. For example, if you start with Java and go to C++ the fact that memory management is now a requisite part of a program will be a hinderance in learning C++. On the other hand, going from C++ to Java is completely trivial. Outside of some cute perks, Java is a simplified version of C++.

I believe this is even more true when you get to very high level languages like Prolog. I used Prolog for a discrete mathematics class and the language was extremely simple to learn. My only hinderance would have been that at times it felt like a glorified database interface language rather than an actual and independant programming language. I have not used Eiffel or O'Caml.

EDIT: And, yes, this does imply if you were to master assembly you would be easily able to pick up any other language and I completely believe this. As much as people dwelve on things such as the OO, XP, whatever.. They are nothing except abstractions of the lowest level code -- assembly. If you understand what it is exactly abstracting then it is naturally trivial to understand its purpose.

[edited by - haro on September 3, 2003 3:19:18 PM]

quote:As much as people dwelve on things such as the OO, XP, whatever.. They are nothing except abstractions of the lowest level code -- assembly.

This is true for C++, but not necessarily for languages meant to run on virtual machines that optimize specificly for OOP style programming.

One thing that C++ programmers do over and over in Java is to try to optimize their code by removing method calls, manually inlining methods. This instead tends to slow down the code because the optimizations of the VMs, such as Hotspot's JIT compilation, were designed for clean OOP code with many small methods rather than monolithic blocks of code.

Instead of knowing how the processor works, you need to learn how the VM works to become a good programmer in a language like Java or C#.

quote: I noticed they were both garbage collected, yet O'Caml's performance is said to be very competitive with raw C.

Garbage collection has little effect on the performance of optimized application. Anyone who knows how a garbage collector works can often optimize away its impact.

[edited by - HenryAPe on September 3, 2003 4:08:33 PM]

quote:Original post by HenryApe

quote: I noticed they were both garbage collected, yet O''Caml''s performance is said to be very competitive with raw C.

Garbage collection has little effect on the performance of optimized application. Anyone who knows how a garbage collector works can often optimize away its impact.

To expand on this, a garbage collected system can even be more effecient than manual memory allocation. Why is that? Well, with a garbage collected system,

new 

just has to move a stack pointer, whereas in c++ you have to search the free list, etc. Furthermore, your objects are more likely to be allocated contiguously, which in some applications will result in better cache coherency.

quote:Original post by haro
EDIT: And, yes, this does imply if you were to master assembly you would be easily able to pick up any other language and I completely believe this.

Even chinese, for example? Actually I''m sort of serious with that, because some computer languages do have very different approaches to programming -- so different that mastering Asm helps you as much with learning Lisp as it helps you with learning chinese. Nobody learning Lisp would try to learn it by figuring out how the expressions are turned into assembly code.

quote:Original post by sjelkjd
To expand on this, a garbage collected system can even be more effecient than manual memory allocation. [...]

Google The Measured Cost of Conservative Garbage Collection.

quote:Original post by haro
EDIT: And, yes, this does imply if you were to master assembly you would be easily able to pick up any other language and I completely believe this.

Generally, HLLs imply abstract virtual machine semantics within their language specification which has little relation to the semantics of the actual machine. That means there would be very little transferrable knowledge going from assembly to HLL or vice-versa. To prove that point, consider that you can write Java programs which ultimately execute on either Intel or IBM z800 architectures, yet the architectures of those machines are very different to one another.

quote:
As much as people dwelve on things such as the OO, XP, whatever.. They are nothing except abstractions of the lowest level code -- assembly. If you understand what it is exactly abstracting then it is naturally trivial to understand its purpose.

OK, so how would having knowledge of assembly make it trivial to understand, for example, the multiple-inheritance model of C++ or the method resolution system of CLOS?