> Hello ! I'm just trying to get some answers to know do some people like to program with low level languages like assembly, and others like to program with high level languages, like c/c++ or java.
Yes.
> If it's easier program with high level, why some keep using assembly, when, c/c++ could get the job done ?
I wrote a simple "mastermind" game under windows to see what the differences were. I wrote it in TASM assembly, Delphi (PASCAL), Microsoft Visual Basic, and Borland Builder (C++).
The issues I noticed were
1) Speed of coding
2) Ease of coding
3) Size of executable
4) Speed of executable
5) Portability (installation issues)
6) Most fun to program
1) Speed of coding
Rankings: C, PASCAL, VB, Assembly
I had some problems fighting the compiler with VB, but if I did a lot of VB programming that wouldn't be an issue. It took about two hours in C, 3 for Delphi, 5 for VB, and 8 for assembly.
2) Ease of coding
Ranking: C, Assembly, Pascal, VB
I had fits with VB doing arrays of controls. Also fighting the compiler because the Windows API documentation was done for C. Translating everything to VB and trying to figure out exactly how they store their strings and such was a major pain in the butt. Assembly was rather straightforward. Coding in C was like a breath of fresh air after the restrictions of VB and PASCAL.
3) Size of Executable
Ranking: Assembler, C, Pascal, VB
The assembly exe was 8K. Actually, the VB exe was 23K, but then there's this 600K dll that you have to include. Both the C and Pascal executables were just over 200K. I linked them without the runtime libraries, for ease of installation.
4) Speed of executable
Ranking: Assembly, C, Pascal, VB
Actually, for a program this small it was pretty hard to really notice a difference for most things. Everything in the Assembly version was virtually instantaneous.
5) Portability (Installation issues)
Ranking: Assembly, C, Pascal, VB
e-mailing an 8K program that you just click on to run is just a breeze. There was no installation. Same for the C and Pascal versions, except they were bigger. VB is a major pain in the patoot if you plan to actually release a product.
6) Most fun to program
Ranking: Assembly, C, Pascal, VB
Of course this is highly subjective. If there had been a lot more user interface stuff, the Assembly would not have been as fun. However, the main part of the program was to get the computer to guess they color code the human was thinking of. The AI involved was fun to do in Assembly.
What I find is that all languages have their advantages, and most of them have some applications that they will be the best fit for. If you want a quality application, nothing beats assembly. However, you pay for it in development time. For large projects, it is usually not cost effective. And with my small program I didn't even have to address maintenance issues and bugs. My Assembly program was 25 times smaller, and only took 4 times as long to program as the closest competitor. As the project gets larger, these numbers would probably gravitate more towards the higher level languages.
Another issue that probably plays a bigger part than any other is politics. When a company is creating a product and deciding which language to use, they seldom choose the language that will provide the better product. Usually, management makes a decision based on recommendations by the marketing guys. A lot of times it really depends on which languages your programmers know, or which programmers you can pay the least to hire. In reality, small fast programs make less money than big slow ones. You can sell more expensive hardware if your program needs it.
When I write programs for work, I write in the language my boss tells me to. Luckily for me, that is usually Assembly with some C. When I write programs for myself or to sell, I choose the language that will make the best product. That is usually a mixture of languages. Most of the control and user interface is done in C, but the lower level stuff is done in Assembly. My VxD's and drivers are always Assembly. When I write for Linux or Unix, or even NetWare, it is almost always C with Assembly support. Sometimes, as you so nicely put it, C++ could "Get the job done". However, there are some times that C just can't do it, and even more times when C *could* do it, but just not as well. Then I will either resort to inline assembly or build routines in assembly and link them in.
Many programmers never learn Assembler. When I was first learning the Windows APIs, I asked for help from several newsgroups and other sources of talented programmers. I asked for examples, books, or tutorials on how to write a windows program in Assembler. This was several years ago when there weren't any. Almost without fail, when I got a response, it wasn't helpful at all. Instead of suggestions, I got "Why in the world would you want to do that anyway?" I often wonder how these guys debug their code. There have been many times when I have followed my code in the debugger down into disassembled code, to track down bugs. Sometimes I wouldn't have found it if I hadn't examined the code the compiler generated. I've even had the compiler generate faulty code before. How do people that don't know Assembly debug this kind of bug?
The last point is that although a lot of times "it's easier program with high level", not always. The best language to use depends on several things, the most important being exactly what it is you're programming. You don't write a compiler in APL, or a web page in lisp. Similarly, writing an AI algorithm in html or oracle would probably be foolish.
