Honestly, I can only think of a couple of reasons why one wouldn't want to program in Assembly...
-not up to (or afraid of) the challenge
-not willing to stare at code for a while (while program if you don't want to???)
-not wanting to write the fastest functions/programs possible
And, why are we programmers if you aren't 1) up to a challenge and 2) you don't want to spend time debugging challenging code and 3) you don't want to write the...best code!!!
Can somebody explain this to me???
1978 Silver Anniversary Corvette
Assembly is good, but only when needed. For example, if C is fine, use C. Why not use the technology if it's there? However, there will almost always be a need for asm, so it is good to know. However, if one is writing a large complicated application, using asm (for the whole thing) would be ridiculous. It would make the code so long and painfully ugly to read that it would take much longer to complete the app and fix problems.
>would make the code so long and painfully ugly to read that it would take much longer to complete the app and fix problems.
Yah painfully ugly! You said the best line I've heard in weeks.
Developing under assembly is very tedious. Furthermore, the resulting code won't be easily portable because it is hardware dependent.
That's why good programmers choose C for optimum efficiency-- it creates low-level, fast, and easily portable code.
All men are created equal. But some are more equal than others.
Visit me at http://www.angelfire.com/my/billholm
>would make the code so long and painfully ugly to read that it would take much longer to complete the app and fix problems.
Yah painfully ugly! You said the best line I've heard in weeks.
Developing under assembly is very tedious. Furthermore, the resulting code won't be easily portable because it is hardware dependent.
That's why good programmers choose C for optimum efficiency-- low-level enough to make fast but easily portable code.
All men are created equal. But some are more equal than others.
Visit me at http://www.angelfire.com/my/billholm
I understand the thinking of people like Compuboy (who spends his time writing stuff that's about as low level as you can go), and people who use inline assemblers for games, but for most platform applications, ASM is too tedious......
Wow...I might have an app that takes virtually no disk space (when diskspace costs zip) and can do things in a few less cycles (as if its often noticable!)....but compare that with code that is hard to manage and has real portability problems (not just between platforms but between assemblers) then you should agree that C++ is the daddy!!.........
I started to write a notepad clone in TASM a few months back....did quite well...it came up on screen....had icons, menus and invoked a few system dialogs (for printing, text searching and opening files) and actually managed to open files and display them....but it got way too tedious after a while.....and I havent got anywhere near to finishing it.......
Well, according to your logic, Java should be the daddy.Wow...I might have an app that takes virtually no disk space (when diskspace costs zip) and can do things in a few less cycles (as if its often noticable!)....but compare that with code that is hard to manage and has real portability problems (not just between platforms but between assemblers) then you should agree that C++ is the daddy!!.........
No need to go over the top now!!!Originally posted by tim545666
Well, according to your logic, Java should be the daddy.
"This would probably be easiest, but who's here writing their own language? "
Well im writing a compiler currently.
I think that you might need to use some assembly to write device drivers. Other than that, you are much better off using an OOP language, infact C is basically too low level for large scale projects. Ofcourse it is impossible to get away from C, since all OS's that I know of are written in C.
The best course of action in my opinion is to use the UML and a process in order to document all of the details including the user needs and the scope. A process assists construction, they are using an interative and incremental approach these days, much better than the waterfal methodology.
OK, I admit that C is often better when higher-level code is required. I often use C and C++ to write my more complicated programs. I do, however, believe that anyone who wants to become a decent programmer should have at least a basic understanding of ASM. Whenever I'm programming in C/C++, I'm constantly aware of how slow the code will run compared to an ASM equivalent. When it comes to very complex code, of course, C/C++ usually becomes easier to write and maintain.
Speed is nonesence. The real issue is learning ASM or C for the sake of planning software architectures. If you are writting programs for embedded technology than that might be a different story, but to be honest I don't believe that anyone here is writing large scale programs, nobody seems to know screw all about project management and process.
>> but to be honest I don't believe that anyone here is writing large scale programs, nobody seems to know screw all about project management and process.
Quite wrong there. But it's my word against yours
Now, you ask a programmer involved in the development of IBM's latest database management toy, DB2, what he knows about project and process management and he may reply he knows squat. And that doesn't mean he's not involved on a large scale project. That's why some of us are programmers and some of us are project managers.
Regards,
Mario Figueiredo
Using Borland C++ Builder 5
Read the Tao of Programming
This advise was brought to you by the Comitee for a Service Packless World
Still a programmer must know the requirements captured in the use case. Other programmers must integrate their classes into the system as a whole and they must follow construction guidelines. Being a developer is not all about writing code. Most of it is not about writing code, but instead planning.
Case Tools are among us for a long time and the UML standard have already stabilized and become a defacto for a long time. First time I used Rational case software it was like what?... 5 years ago?
Trust me. There's a lot of people using it. There is still traditional analysis, mind you. Many developing teams still go from the usual ERDs and DFDs and such directly to code with few to no problems at all, even on large scale projects. UML is meant to ease the transition. It doesn't substitute any of the steps and it surely is not an absolute truth. It's there for those who are enlightened enough to appreciate the advantages.
But sticking to the subject line of this thread... it's somewhat amusing that by evolving the discussion to case tools we are indeed getting even further away from Assembly as an all-around solution for software development
Regards,
Mario Figueiredo
Using Borland C++ Builder 5
Read the Tao of Programming
This advise was brought to you by the Comitee for a Service Packless World
>> I think that you might need to use some assembly to write device drivers. <<Originally posted by Troll_King
I think that you might need to use some assembly to write device drivers. Other than that, you are much better off using an OOP language, infact C is basically too low level for large scale projects. Ofcourse it is impossible to get away from C, since all OS's that I know of are written in C.
The best course of action in my opinion is to use the UML and a process in order to document all of the details including the user needs and the scope. A process assists construction, they are using an interative and incremental approach these days, much better than the waterfal methodology.
Device drivers are written in most assembly because of the necessary low-level ness needed of the hardware.
>> infact C is basically too low level for large scale projects. <<
C can do everything C++ can do. OOP is only for organization...
>> Ofcourse it is impossible to get away from C, since all OS's that I know of are written in C. <<
There have been operating systems written in full Assembly. In fact, I'm writing my OS in full Assembly!
1978 Silver Anniversary Corvette
