• Advertisement

#### Archived

This topic is now archived and is closed to further replies.

# Beyond C/C++/C#/Java

This topic is 5278 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

## Recommended Posts

Great quote from my comparative languages teacher: "I''m here to try to teach you to not take computer languages seriously." Now when I heard that I knew I was one of the ones that takes them seriously. It borders on religious wars with a lot of people. You get it ingrained that "C++ is the way" and you lock yourself into imperative/half-assed OO (single dispatch comes to mind) constructs, when in reality all you''ve done is buy into the popular opinion that C/C++ is the way to go on most projects. No, it isn''t hype, but at the same time it isn''t much better. I can only hope that the time I''ve spent in C++ does not hinder me greatly when it comes to learning ML and Prolog. The past few days I''ve (outside of class) looked at various different languages such as Eiffel and O''Caml. Eiffel looks really neat and amazingly clean, as does O''Caml''s blend of imperative/functional/OO into one language with decent syntax. I noticed they were both garbage collected, yet O''Caml''s performance is said to be very competitive with raw C. Has anyone worked on either of these languages? I''d be interested to know what you thought of them for larger projects.

#### Share this post

##### Share on other sites
Advertisement
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]

#### Share this post

##### Share on other sites
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]

#### Share this post

##### Share on other sites
quote:
"I'm here to try to teach you to not take computer languages seriously."

Why?

If you want to play the quote game, here one from a guy I met that works for IBM's Transarc Labs:
quote:
"If you can do [learn] C, you can do [learn] anything."

I don't think C++ is going to hinder you.

----
I think, therefore I''m annoying.
http://www.downfromearth.com

[edited by - HarryPawedHer on September 3, 2003 4:18:59 PM]

#### Share this post

##### Share on other sites
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.

#### Share this post

##### Share on other sites
quote:
Original post by haro
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 think the reverse also holds true. While someone going from a lower level language to a higher level language will probably be able "pick it up" quickly, it may take them quite some time to grasp the higher level constructs, and un-learn old behaviors. A classic example of this was/is people going from C to C++ and having trouble really understanding how to implement good OO constructs.

It''s all just stuff to learn

-John

#### Share this post

##### Share on other sites
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.

#### Share this post

##### Share on other sites
Functional programming languages like ML are very different from imperative languages like C++ in terms of the way you have to think about problems. I think it''s beneficial to learn them because they do give you a very different perspective on things if you''re used to imperative languages. Learning a language like ML will also help you understand C++ template metaprogramming which is very functional in style. I don''t think knowing C++ is necessarily a hindrance to learning ML as long as you don''t assume that everything you''ve learnt about C++ can be directly applied to ML. Keep an open mind and be prepared to learn the ML style rather than trying to write ML in a C++ style and you won''t have a problem.

#### Share this post

##### Share on other sites
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.

#### Share this post

##### Share on other sites
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?

#### Share this post

##### Share on other sites
quote:
Original post by SabreMan
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?

In the lowest level assembly ( as opposed to a HLA ) all information is obviously public. This doesn't mean there isn't encapsulation, even though encapsulation isn't supported in the language. I think that encapsulation should be one of the most natural concepts to most of any programmer. I would also argue that encapsulation is more important in assembly than in any HLL. Poorly organized assembly is a HELL OF ALOT harder to read and work with, than any poorly organized HLL's.

Yes, I am going somewhere with this. Classes are simply an abstraction of encapsulation. You are storing data and code in an area seperated from the rest of the program for the sake of clarity and simplicity. Inheritance, I feel, is not completely intuitive but extremely easy to understand once you understand the purposes of classes, and the fact that many classes are directly related. And again, multiple-inheritance is significantly less intuitive than single inheritance but an obvious concept once one understands single inheritance. Programmers who start with a high level language will almost definitely not understand the purpose of encapsulation for quite some time ( and hence, the ladder-- encapsulation -- functions -- classes -- inheritence ), but those who begin with assembly will, comparatively speaking, rapidly realize the purpose behind the modern code design. I am a vehement follower of the idea that universities should offer assembly as a first language to new programmers, and not a language such as Java. I can't imagine how difficult it would be to understand what you are doing without a familiarity of WHY you are doing it that way, which I would propose is also the reason for the excessively large number of virtually inept CS graduates even from top tier universities, although that's another rant.

This is also all coming from my own experience. My first 'real' language was 16bit 8086 assembly, using "debug.exe" as my 'compiler' in DOS. When the only way I could write 'non-impromptu' programs was piping input into debug from a single linear file, I quickly learned the value of writing a block of code that accomplished its goal, and then storing that code in a seperate area and moving on. From there I later learned C, QBasic, COBOL, Pascal, Fortran, C++, Scheme, Lisp, Java. I have never had any problem at all picking up any language after assembly, and this includes the functional languages. The only potentially negative fact is that I don't see any purpose in some higher level language features such as inheritence. Outside of group projects where I was not the lead and academic projects, I have never used inheritence... although I have made extensive use of other higher level language features such as templates.

If I might add my own quote: "If you can master assembly, you can master anything."

[edited by - haro on September 4, 2003 1:10:09 PM]

#### Share this post

##### Share on other sites
quote:
Original post by haro
I can''t imagine how difficult it would be to understand what you are doing without a familiarity of WHY you are doing it that way
I agree, but could you explain how asm in particular helps one to understand WHY I should use inheritance, as asm doesn''t have the concept of inheritance, or even classes. Why you should use inheritance is not something you can explain with asm. You have to explain it within a higher abstraction level.

I can''t really see any logic in your statements that asm should be learnt first. Nobody starts learning biology by learning about organic cells. They start from a higher level (from "objects" such as animals) and then learn the details. The same concept is used in just about everything that is taught, and has been used for thousands of years. It''s so simply because higher level concepts are more useful and it''s usually easier to grasp their purpose. If you''re presented a cell that just dies if left alone, it''s hard to undestand it''s meaning, and it''s quite far from the world we''re used to. But if you see a rabbit and study how it works, you''ll understand the meaning of cells. Similarly, a high level language can show you how to do math as we know it (familiarity) and how to easily make programs as we see them (purpose).

And now you come stating that we should start from the insignificant details and work our way up to higher levels of abstraction. I can''t describe that with a better word than "ridiculous".

#### Share this post

##### Share on other sites
I should have no problems learning anything in this world, since I know how an atom works.

#### Share this post

##### Share on other sites
Perhaps, but only if you truly know how an atom works.

#### Share this post

##### Share on other sites
quote:
Original post by SabreMan
Google The Measured Cost of Conservative Garbage Collection.

Is that the same Zorn as in "Zorn''s lemma"

He must be really old by now.

#### Share this post

##### Share on other sites
quote:
Original post by Arild Fines
I should have no problems learning anything in this world, since I know how an atom works.

I actually completely agree. If you knew, beyond a doubt, exactly what and how an atom worked and interacted with any other atom under most any reasonable circumstances then yes -- I think you should be able to trivially derive anything else in the world.

The fact that what I described is impossible, and likely to remain so for the existance of humanity is but a side note.

#### Share this post

##### Share on other sites
quote:
Original post by civguy
I agree, but could you explain how asm in particular helps one to understand WHY I should use inheritance, as asm doesn't have the concept of inheritance, or even classes.

< see above >

Though, as mentioned, I still have never used inheritence in a private project or group project where I have been the lead. I think it makes things unnecessarily complicated. And yes, I realize its purpose is to alleviate program complexity but I enjoy knowing exactly what a class is made up from a single glance at the class's header file. Not that class's header, and then its parents' and the parents', etc.. Not to mention all the mess of bothering about the side effects of the parent's constructors, etc.. Its just a hassle.

[edited by - haro on September 4, 2003 12:51:14 AM]

#### Share this post

##### Share on other sites
quote:
Original post by haro
If you knew, beyond a doubt, exactly what and how an atom worked and interacted with any other atom under most any reasonable circumstances then yes -- I think you should be able to trivially derive anything else in the world.

No he wouldn't. Atom interaction is so far away from, say, human psychology that you can take a lifetime of deriving psychological behaviors from atom interactions and won't get anywhere. The abstractions are so far away from low level, understanding low level will not give you an understanding of the abstractions.

[edited by - CoffeeMug on September 5, 2003 1:02:30 AM]

#### Share this post

##### Share on other sites
Inheritence is also used to provide dynamic dispatch(despatch?) in many languages. When used properly, it is less complicated than the alternative.

#### Share this post

##### Share on other sites
quote:

I am a vehement follower of the idea that universities should offer assembly as a first language to new programmers, and not a language such as Java. I can''t imagine how difficult it would be to understand what you are doing without a familiarity of WHY you are doing it that way...

...I have never had any problem at all picking up any language after assembly, and this includes the functional languages. The only potentially negative fact is that I don''t see any purpose in some higher level language features such as inheritence.

This is what I was alluding to. Once you are really comfortable at a high(or low) level, it takes work to understand things going in the other direction.

BTW, inheritence has all kinds of uses..I''m sure you''ll find some of them useful in time Though, like anything, in the wrong hands it can be abused and hinder more than it helps.

-John

#### Share this post

##### Share on other sites
quote:
Original post by haro
The fact that what I described is impossible, and likely to remain so for the existance of humanity is but a side note.
If you think that Arild''s example of atoms or mine of cells was too unprecise since one can''t know their functionality exactly, then how about math? Learning the axioms is trivial, and there aren''t too many to memoize. Yet it''s not trivial to derive everything in math -- far from it. To disprove me, you could start by showing me if Riemann''s hypothesis is true. Is this enough to convince you that your theory is nonsense?

#### Share this post

##### Share on other sites
quote:
Original post by haro
In the lowest level assembly ( as opposed to a HLA ) all information is obviously public. This doesn''t mean there isn''t encapsulation, even though encapsulation isn''t supported in the language.

[Aside: you''re talking about information hiding, which is not the same thing as encapsulation.]
quote:

Yes, I am going somewhere with this. Classes are simply an abstraction of encapsulation.

Even experts cannot agree on the idea of what a class actually is - just take a look at the different implementations around. In C++ a class is a rather confused construct, both a means of grouping objects and a namespace for symbols to live, which produces lots of problems when symbol tables clash together (and even when they don''t). In CLOS a class does not imply a namespace, meaning that it is not the class mechanism which is providing for encapsulation - there is a distinct and intentional mechanism for that purpose.
quote:

You are storing data and code in an area seperated from the rest of the program for the sake of clarity and simplicity.

I would argue that you are doing it to model the problem domain as closely as is possible in the language you are working with. Clarity and simplicity are byproducts of doing that well.
quote:

Inheritance, I feel, is not completely intuitive but extremely easy to understand once you understand the purposes of classes, and the fact that many classes are directly related. And again, multiple-inheritance is significantly less intuitive than single inheritance but an obvious concept once one understands single inheritance.

Inheritance is not an obvious concept - its a very widely misunderstood and abused concept, as evidenced by the amount of literature you can find regarding inheritance. Consider the difference between inheritance in C++ and, say, Python. In C++ it is a limited means of expressing object relationships, aswell as a means of sharing code. In Python inheritance takes on a lesser role as a `code-sharing hack''. Learning assembly is not going to help you scrape the surface of this - its not even going to let you play around with implementations of the concepts (unless you''re using an OO assembly).

To quote the TUNES glossary:
quote:

Inheritance is the typical example of an element of tradition that people mistakenly consider as being holy, and refuse to reject even though reason demonstrates how inadequate it is for all the purposes it was proposed for. It used to be a nifty hack to achieve a few high-level things at reasonable cost in low-level languages, and was since presented as a universal panacea for program design, despite its being a conceptual mess, and a brake to a really clear understanding of programming.

quote:

Programmers who start with a high level language will almost definitely not understand the purpose of encapsulation for quite some time

The purpose of encapsulation is quite easy to understand. Employing the right mechanisms in order to achieve the ends is a different thing entirely. I disagree that encapsulation is more important in assembly than in any other language, so I also disagree that assembly will help teach encapsulation any quicker or any better than another language. The argument that it would be easier to learn about encapsulation in a language which provides for it seems more compelling to me.
quote:

If I might add my own quote: "If you can master assembly, you can master anything."

I spy a logical fallacy.

#### Share this post

##### Share on other sites
Well a lot of people usually go as far with their optimizations that they try to beat the compiler, which is almost impossible unless YOU know the platform/compiler really well. When you try to beat the compiler, don''t.

#### Share this post

##### Share on other sites
quote:
Original post by CoffeeMug
No he wouldn''t. Atom interaction is so far away from, say, human psychology that you can take a lifetime of deriving psychological behaviors from atom interactions and won''t get anywhere.

Actually, a behaviorist would completely disagree with you and I must say that behaviorism is somewhat more respected than introspectionism.

#### Share this post

##### Share on other sites
quote:
Original post by civguy
If you think that Arild's example of atoms or mine of cells was too unprecise since one can't know their functionality exactly, then how about math? Learning the axioms is trivial, and there aren't too many to memoize. Yet it's not trivial to derive everything in math -- far from it. To disprove me, you could start by showing me if Riemann's hypothesis is true. Is this enough to convince you that your theory is nonsense?

To start with, Riemann's hypothesis is a a derivitive of calculus and modern calculus theory is based solely upon theories. Much like modern physics is based upon theories, though there is significant demonstrable proof of the respective theories, they are theories none-the-less and basing any philosophical argument (which this essentially is) upon an unproven 'given', is inheritly not a tautological and hence-- invalid, argument.

EDIT: That counter-argument came out exceptionally bloated. Being a bit more down to earth, Riemann's hypothesis has not been proven and so isn't particularly relevant to this conversation. I was talking about using the fundamentals to learn what is already known but on a significantly decreased learning curve.

This would be analogous to trying to learn calculus without knowledge of addition, subtraction, division, multiplication, substitution and all other basic properties of algebra, etc.. It is most assuredly possible. It is clearly possible to perform calculus functions without knowing what you are doing as is shown by the fact that computer's can derive/integrate/etc without any knowledge but just a set of rules. However, if you actually know what you're doing and why it works, then you can learn advanced math significantly more easily.

Programming without knowing the lowest level information would be appropriately analagous to performing calculus, only using a calculuator whenver you came to one of those unusual (*/+-) signs (or when the rule dictated you should insert a */+- yourself. Very possible but also very difficult.

[edited by - haro on September 5, 2003 3:22:11 PM]

#### Share this post

##### Share on other sites

• Advertisement
• Advertisement
• ### Popular Tags

• Advertisement
• ### Popular Now

• 24
• 11
• 17
• 11
• 13
• Advertisement