Okay, I really don't want to be the beginning of an endless argument about which is better, all I'm asking for is a couple of up and downsides about each language.

I'm really wanting to learn something that is a lot closely related to machines that I'm using at the time so maybe I can have more control over how to work or something that is going to give me a really good challenge.
All I have done when it comes to programming is Visual Basic .NET, Python, PHP and MySQL a little but I think I'm more of a "down-to-earth" person rather than being up in the clouds of the internet and I really want to learn something that I can be a good programmer with if I put in the time and for that, I need something that interests me which both of these interest me more than any other languages.

So I was wondering if anybody could tell me some good up/downsides to learning Assembly and C++ and if possible or anybody knows of a good resource, where I could find a good tutorial or some type of documentation for ASM.

But I will be working under a Linux enviroment probably all the time. I'm currently on Ubuntu 9.10 but thinking about going over to something a bit different. Would either of these languages be of any use to me?

I understand that there are certain differences to both of these but what interests me most about ASM is that it's so closely related to machine language and I think I may find that useful in the future. Another question is, if I were to learn ASM, could I more quickly pick C++ up in the future?

(Half) seriously "C" is somewhere in between, so consider it too.

C/C++

Here is a personal view and you will almost certainly find that there are contradictory personal views

...if you want those, you can get those, but why are you then asking questions that don't align with the 'give me a limited number of bullet points' that you seem to be asking for with these words?

I'm going to regard everything there, with the exception of python to be a bad start, but then its never too late...

The first and most obvious point to make about assembler is that it is not one thing: there are assemblers for every processor family under the Sun (even SPARC!) and knowing one doesn't necessarily do much more than helping you with the overall structure of another.

I'm guessing, from the context, that you possibly consider this to be irrelevant, as 'everything today is some variant of x86'. This isn't really true: everything PC is x86, but ARMs practically own the mobile 'phone space and have a large presence in other low power situations, too. Itanium (really), SPARC and the Power arch are still hanging in there in their own respective niches and there are dozens of other Archs that have significant presence in the embedded space. For these apps, knowing x86 assembler will get you some way up the learning curve for one of these others, but won't get you to the point at which you can be instantly productive.

You do not distinguish between the system on which you compile the code and the one on which you execute the code (a distinction which is routine in embedded), so I guess that you intend code to be executed on typical desktop systems: If this is your aim, why would you bother with assembler? You will make your productivity lower, at least at first, although you might get faster execution.

I consider this more than a half serious point: depending on what you want to code, and why you want to code it, C may be as good/a better choice than C++.

ASM will probably help you the least in helping you to pick up higher level languages, so almost anything else would help you more. So, although strictly the answer question that you have asked is 'yes', a more helpful answer seems to be 'yes, but not by as much as almost anything else'.

Anyway, some quick and dirty bullet points, which inevitably oversimplify things (and if we knew what kind of coding you wanted to do, this could be more directed; faced with this level of guesswork, its going to be more generic):

ASM
For

• very close to underlying machine arch
• potentially the fastest execution times (although isn't usually as relevant as is thought); in some unusual difficult cases, it may be the only option

Agin

• too close to underlying machine arch; programs not (easily) portable
• too close to underlying machine arch; learning not (easily) portable
• difficult to be productive in writing large apps

C++
For

• not close to underlying machine arch; learning is portable
• abstraction and hiding: easier to be productive in writing large apps
• possible to be productive in writing large apps; not as easy to work with as, say, python, but easier than ASM (even for people who don't really like this kind of thing)

Agin

• not close to underlying machine arch; not learning the underlying machine
• difficult to use for real-time apps

C
For

• not that close to underlying machine arch; learning is portable
• fast execution times (although isn't usually as relevant as is thought)
• with toolkits, etc, etc, it may be possible to be quite productive

Agin
possibly, more difficult to be productive in writing large apps than C++
Easier to use in real time than C++ and other OO languages

Python
For

• not at all close to underlying machine arch; learning is portable
• slowest execution times (although isn't usually as relevant as is thought)
• Can use lower level languages for speed critical portions of code
• with toolkits, etc, etc, it may be possible to be quite productive in even writing complex graphical apps which run acceptably quickly

Agin

• Speed
• not at all close to underlying machine arch; don't learn the machine
• need to use non-core features (eg toolkits, etc) for graphical apps, and documentation for these can be fragmented, although with correct use of these, speed may be comparable with other approaches to these problems
• Hard to use in real time

For me, there are some things that it would make sense to code in Python (with toolkits and language extensions, although that can be a bit of a pain from a 'getting clear, unambiguous and simple documentation in one place' point-of-view and C for stuff which is too difficult to do in python and I don't see where anything else fits in (apart from the shell...we haven't mentioned the shell).

1 members found this post helpful.

Ah, Okay. I guess I didn't understand it as much as I thought to begin with but you what you have said has helped me understand it better. Thanks for taking your time to reply. I think I'll go with C/C++ and try to learn a bit of both further down the line.
Thanks again.

I couldn't disagree more strongly, at least if the high level language you intend to learn uses pointers, as is the case with C/C++. The use of pointers in these languages will very likely confound you more than any single concept, especially with your background in languages that are a much higher level of abstraction of the machine. Learning any assembler language prior to learning C will make the concept of pointers much clearer and easier to learn. C has been described as a high level assembler language, which I see as a fairly accurate portrayal. As such, many concepts used in assembler language are evident in C, and learning these concepts in assembler language will smooth the way to understanding them in higher level languages.

Most of the rest of what salasi says seems accurate, to me.

--- rod.

I think I both agree and disagree with that. ASM will help with some of the concepts and methods (like pointers, malloc, etc), but otherwise it will only really help with an appreciation of C/C++'s string handling ... it's possibly the only language that's less flexible with strings than C.

I always think learning ASM is a good idea. I just don't know that it really helps understanding higher-level languages, I think it helps more with understanding computers. Understanding computers is probably far more valuable.

Hard to avoid when you ask that kind of question.

C++ is the best (overall, not just vs. assembly) language for most programming tasks. It is almost impossible, and generally unnecessary, to learn the whole language. But the mere existence of the parts you don't need to learn tends to make it harder to learn the parts you should. It would be easy to select and teach a good subset of C++, but most C++ tutorials do not do a good job of selecting a subset.

Assembly is rarely the right language for any task and getting rarer. Even in embedded systems, C++ is usually available and better.

Knowing ASM will do very little to help you "pick up" C++. Knowing ASM will do a lot to help you write efficient code (when that is required) in C++. Knowing ASM will do a lot to help you debug difficult bugs in complicated C++ code. But those things matter after you have learned a lot of C++. ASM won't help much when you start learning C++.

Sorry, I just know about lots of bad resources. They teach obsolete ASM (32 bit x86 or even 16 bit x86, when they should be teaching x86_64).

Most focus on the ability to write complete programs in ASM, which is a complete waste of time.

There is a lot of complicated worthless knowledge you need for program skeleton, startup, I/O and shutdown in ASM. None of that will do you any good in the few situations where ASM is the best language for real work and none of that will do you any good in using ASM knowledge to do better work in other languages.

To learn ASM, you should write functions in asm that are called with a C interface by a program in another language (any language you know that can call C interface functions is fine. I use C++ or Java to call C interface functions in ASM, but there are lots of alternatives).

Other tutorials teach the GCC language for embedding ASM instructions in C or C++ code. That is a very difficult language unless you are already expert in C and ASM. It is a terrible place to start. If you are writing anything other the OS modules, it is also a skill of questionable value. In most cases where you need ASM, even for extreme performance, you can afford the overhead of a function call. It is cleaner, easier, and more maintainable to write a whole function in ASM and call it from C or C++ than to write part of a function in embedded asm. There are exceptions. All the important ASM work I've done in my job in recent years has been with that embedded syntax and purely for performance, not in an OS. But that is a rare situation and expert only.

1 members found this post helpful.

Do it my way, learn C first then ASM.

And as high contrast between C & Assembly you can learn both in parallel.
I did that. non-confusing.

C a high level language?...but it uses pointers

.

I will admit that this is a good point, but it is only one of many things that you have to learn, and some people will have more difficulty with this than others.

I agree.

I learned ASM for several different architectures in 1971 before I had any idea that high level languages supporting pointers even existed (several did).

When I learned C, pointers seemed totally natural and obvious. Was that because I just think that way, or was it because I already knew several architectures of ASM. I don't really know.

It never felt like knowing ASM was important to understanding pointers, but I never had the experience of learning to use pointers before knowing ASM.

There is a lot to learn in ASM, so even if learning ASM does make understanding pointers in C easier, that is too small a part of learning C and too large a task (learning ASM) to say learning ASM first is justified by making C easier to learn.

An alternative might be learning, say, the JVM language, i.e. the language into which Java is translated, or the ancient P-code, or the modern Parrot ...

As you have no doubt discovered, you have unleashed a religious holy-war...

Here are a few of what might be 'useful' observations...

• There is no "one Ring to rule them all." Every situation that someone might be willing to pay for is different. Sooner or later, you are going to have to "soil yourself in the excrement of" a great many languages. (C'mon in... the water's fine...)
• It is always a wonderful thing to be able to easily leverage somebody else's painstakingly-optimized "C" (or "C++" or "asm") code. And so, anytime you are able to use one of the mainstream "this is not C or C++ or asm" languages, you should be aware that you are doing precisely that. (The (hundreds of...) programmers who wrote languages like Perl or PHP or Java or Python or what-have-you are TRUE WYZARDS, whose skills are far beyond those of Mere Mortals like you 'n me. Anytime you can coat-tail upon their trails of "magickal pixie-dust," do so!)
• These days, you almost never have to seriously worry about how long it will take the computer to do whatever you ask. ("At several billion ops per second, nobody can hear you scream...") The very-expensive resource that you need to seriously optimize is ... you.
• It is an absolutely fabulous thing to be able to implement a complete Web server in three lines of Perl code... and to know that it will work correctly, no matter what kind of computer (or portable phone... ) you may be using at the time. That is the kind of "efficiency" that you are looking for!

0 members found this post helpful.

Other end of the 70s for me, but otherwise my experience is similar to yours. I had done a trivial course in BASIC earlier, but my first serious exposure to serious programming was ASM, and I didn't subsequently have serious problems with pointers, except for an occasional bit of paranoia about whether that starts from the zeroeth element and whether I've got the syntax right for this language I haven't used for five years.

Whether two people can be considered firm evidence for 'learn ASM first and you'll understand pointers' is a bit of a stretch, particularly in a self-selecting population, but it seems to help some people.

OTOH, I am occasionally slowed down by wondering 'and what are the registers doing here'. This can be a question that is important for efficiency, but efficiency isn't usually important...but it is inelegant to be doing unnecessary stuff with registers in the same way, but more subtly, that it can be inelegant to write bad looking code (Ha! I should talk!).

Of course I am forced to forget all this stuff about registers when using a real high level language. Maybe that is why I can get stuff done more quickly...

@sundialsvcs
...been surprisingly polite and well reasoned for a holy-war...err, so far...

While there are certainly important corner cases in which efficiency is important, and it is a good point, but shouldn't that be 'yawn' and not 'scream'?

And if Linus and his kernel-hacking team took this approach to efficiency, we'd all be struggling through molasses, so it is important that some people take execution speed seriously.