Ran into a great discussion involving assembly language, and want your thoughts.
potatohead
Posts: 10,261
The question was, "What 5 programming languages should every programmer know?"
Assembly language did not get in the mention, so I tossed it in there. Everyone was pretty good about the 5 need to include one scripting language, one core like C, etc...
The reasons for assembly that I gave were the usual things: ability to do low level tasks, understand what the higher level languages boil down to, etc...
Got the most interesting comment: Assembly language isn't a language, but more of a description language for a binary.
What do you guys say to that? I'm very curious to read your thoughts on the matter.
Assembly language did not get in the mention, so I tossed it in there. Everyone was pretty good about the 5 need to include one scripting language, one core like C, etc...
The reasons for assembly that I gave were the usual things: ability to do low level tasks, understand what the higher level languages boil down to, etc...
Got the most interesting comment: Assembly language isn't a language, but more of a description language for a binary.
What do you guys say to that? I'm very curious to read your thoughts on the matter.
Comments
Kids these days. Back in the old days we had to key our programs directly into a microprocessor via a hex pad, and read the output on seven segment displays! But we liked it, we liked it just fine.
-Phil
Those who do not understand hardware are probably best to stay away from assembly language.
But if you need to have full access and control of the hardware - everything, nothing better than assembly language. Note that higher level languages sometimes do not allow the full implementation of the hardware's capabilities or don't do things right. A common "brain damaged" set of higher level instructions is with serial communications for example. Do it yourself with assembly language and you can get it right or do what you want.
What is a "language"?
That is one of those eternal and pointless debates in computing and elsewhere. Clearly assembler programs are using abstract symbols to represent something and there are rules about what valid symbols are and what sequences they can be arranged in. Such arrangements of symbols can be used to convey meaning from one programmer to another as well as being used to program a machine. Sounds like a language to me.
Programmers are kind of snotty about this idea that a programmer should know this or that many different languages. I'm coming to the conclusion that its a silly proposition. I have had to learn many languages over the years, for a long while it looked like every new project I did would require learning a new language. Mostly it was a big waste of time and my mental capacity (which is in short supply) because they were mostly the same idea, only the details differed. For example: Algol, Ada, PL/M. Coral 66, Pascal, C are all the same stuff. Things start to look up with C++, Java, C# and such that offer object oriented programming. Then we have the wonderful world of languages like JavaScript with it's first class functions, closures, prototypical inheritance. In many ways a more advanced language that the C++/Java group at least it includes some concepts that are very different.
All in all a programmer should not have to be learning loads of languages. They should be able to master one and use their energies solving problems in their problem domain with it. They should not have to be language experts but experts in their chosen domain.
One of the happiest programmers I ever met only ever new one language, COBOL. What on earth would she want to care about how the machine works, or two's comp arithmetic or bit shifting etc.
Martin_H,
You were lucky. When I were a lad we used to dream of hex pads and seven segment displays. We had to program by welding diodes to circuit boards. Tell kids that today and they just won't believe you.
http://www.cca.org/blog/20120222-Diode-Matrix.shtml
P.S. Such diode matrix boards are still in use to define the conflict matrices in traffic light controllers around the world.
Yes!
Absolutely. That was the interesting part of it. I never thought of assembly as a description of a binary, but I do agree with that in that is precisely what happens on a good assembler. Heck, on the Apple, an assembler can be used to author a disk image directly bootable on the machine. One nice bit stream containing what is needed to read the disk and run "the program", which kind of blurs things somewhat. A disk can simply contain a program, no DOS, etc... and the developer can do whatever they want to with that diskette... Of course, one can boot the standard stuff, run an assembler and produce just a binary to be placed into the filesystem on the disk too.
@Martin, you said about what I did.
About that happy COBOL programmer... yeah, exactly. She's got her problem domain, appropriate skills and that mastery makes the work enjoyable, productive, etc... no worries at all.
Now this:
Is worth some discussion. Chip and I were having a discussion about SPIN some time back. The root of that discussion was C of course, and all the dialog surrounding whether or not it makes sense to use, is necessary, etc...
Now I'm not taking a position on that, better or worse, other than to say C has a level of interest sufficient to warrant getting good tools bootstrapped onto Propeller chips. We've got it, and it's improving, great!
Chip said the most interesting thing: "Why not simply use the optimized tools?" Those are the best ones anyway, and bending things into tools that one knows can make sense, but not always. Of course, SPIN + PASM on this chip is brilliant. It takes similar amounts of learning to figure out how to best express C for a Prop as it does to express it in SPIN + PASM.
So then, this becomes a discussion of intent, which is nearly always missing from the question, but often supplied in the answers.
Re: Understanding hardware and assembly language.
Well, maybe. For things like drivers and such, sure! I think it makes sense to couple both domains and understand the hardware and the CPU. However, there are lots of places where assembly can do great things without getting too much into the hardware. Depends on the problem domain and where hardware may intersect that IMHO.
And Mike mentioned the instruction set is really the target... Yeah. agreed.
Honestly, one thing not mentioned yet is the nature of the abstractions. Translating higher order tasks to assembly language is a special skill. When I see people able to really do that, I'm amazed at how many abstractions they can work with at one time. However, even at a basic level, the special insight I think is most important is to realize computers really just process information. What that information means is up to those using the computer and factoring that meaning down to structures, etc... that the computer is particularly adept at handling is at the core of what computing really is, IMHO of course.
Great thoughts guys. Appreciated. Please feel free to continue to riff on the thread. I just thought I would like this discussion and hoped a few of you would too.
If you want to know hardware, you use machine code.
Anything else is a language that insulates the user from the hardware.
FWIW..anyone who suggests assembly language as the primary software approach to accomplishing a task has no business doing a software project since it will adversely affect scheduling and maintainance of the project.
Is the project firmware of some sort? What resources is it operating on? Scope of functionality? Etc...
I don't disagree with you in general principle, but there are plenty of cases where well commented, documented assembly language makes perfect sense.
A computer BIOS would be one case that's super easy to identify. Those embedded controls on your microwave may be another extreme the other direction.
Other than that, most software engineers I know only look at assembly language when it's required. It's ok to have a passion for it, but such a passion is definitely not required.
To think that everyone should be excited about assembly is a total disconnect with the rest of the programming universe.
I disagree.
Assembly language makes projects a nightmare for making timely schedule deadlines and future project maintainance.
I have seen countless programs suffer because assembly language was used to make up for poor hardware design selections.
Many times hardware is underpowered and the assembly language is used to patch over the poor system choices.
It can also be "I know assembly language" so why would I want to use a language that I have to learn.
It is the same human condition where you find hardware types who would rather built the project out of all hardware instead of a more suitable hardware/software combo...when you have a hammer every problem looks like a nail mentality.
In the realm of microcontrollers, we see the overuse of assembly language because of the underpowered hardware platforms selected being overtasked and use of a higher level language requires resources the project is unwilling to commit.
Many times the "cost" of a project is calculated by its hardware component alone..with no thought given to the larger overall cost to using inadequate software.
Well said.
It has been said tongue in cheek that those who advocate extensive use of assembly language suffer from the computer science equivalent of OCD similar to the TV detective Monk focus on detail.
Now I agree with you in terms of something like a BIOS. Newer ones may well be developed with an HDL. The PC ones were always annoying to me coming from something nice like ARC (SGI)
I would not agree for something small in scope, such as that microwave.
You're one of the only two 6502 programmer enthusiasts I've met in person.
I don't have enough fingers, toes, etc... to count the number of other programmers I've met
There is lots of embedded code out there...just because assembly language was the ONLY choice long ago does not make it a realistic choice now.
Any analysis of a project's lifetime cost shows that software maintainance is THE major cost.
Many product lines are scrapped because the software cannot be maintained...the developers have left the building.
Agreed.
Knowledge of the hardware is essential.
But that does not make assembly the first choice for any serious product.
Making the product delivery deadline and subsequent product maintainance are the big cost factors in a program. Anything that affects them...hardware or software...are the ecomonic lynch pins of the development.
I have been on programs where the engineering staff want only hardware..no software..and not surprisely none of the engineers knew how to code...so surprise, surprise...they recommended what they knew and were comfortable with.
While on others they wanted software...software that had no possible platform to ever run on...so it was just two sides of the same problem..the designers could not design or innovate.
One of the big problems is that engineering does not accurately estimate the cost of software, when it is needed or not.
and
Fit the subject well. Yes, I don't think many programmers get excited about assembler. But, if they have some desire to understand the voodoo behind the code they write, they may well find the experience worth their time.
I did say it's entirely appropriate for a software project given good alignment on requirements, etc... That has little to do with historical things.
BTW: 6502 code is out there today. Many use C, and that's practical on the 10-14-20Mhz chips out there today. Many use assembly language too. Chances are you have one somewhere nearby. They do lots of little, highly specific things today. Think components and sub-systems with well defined control and performance requirements.
There are more of us than you think. But, not as many as I would like.
So far, the thread equates to assembly not being one of the core things people need to know. Not sure I disagree.
If somebody asked me this and they were programming now, I would qualify it. For somebody starting out on this stuff in general? Absolutely they should know. Way too many basic, core skills linked to assembly language not to. And it's not like they need to reach mastery to gain the benefit either.
Re: Excited about assembly language.
Well, I love it personally. Love a lot of things. But, I really only like it in smaller contexts. I've no interest at all in assembly for an X86 PC or system on a board, etc... On this chip? Assembly is a freaking playground. Lots of fun. Will be on the next one too. It really depends.
Well said.
A language is just a tool...so one uses the right tool for the right job.
I personally like strongly typed languages like Pascal...let the complier do the busy work.
Meanwhile I have seen lots of trash design written in C which costs a company a support nightmare.
My opinion of C has been borne out by the subsequent versions (C++, Csharp,etc.) where typing is tightened up.
One of observation I have seen is that good programmers want strong compliers that type strongly...it frees them up for working the design, not the problems.
'Same applies to the Propeller. For tight video timing loops and real-time signal processing, PASM is the only way to go.
OTOH, if you're programming a PC, there probably isn't a need for most programmers to know x86 assembly. (Still, though, there's the Spin compiler which Chip wrote in assembly for the PropTool, and it's damn fast! 'Haven't compared compilation speed with Roy's OpenSpin compiler, however.)
-Phil
It's also a bit of a put down to all those really good programmers who use weakly of dynamically typed languages. Many gurus of Lisp, Scheme even Forth could give you a lecture on that.
I also observe that Ada, a very strongly typed language, has been resoundingly rejected by pretty much the entire programming community.
potatohead Optimized tools? Yes. The question then is what are wanting to optimize for: execution, speed, size, programmer productivity, maximal cross platform support, correctness/security, profit, etc?
For most coders the answer would be no.
It's just a black box that you code on.
Inside the box only matters to designers, bit bangers and hackers who want to know what goes on. Your average code monkey doesn't need to know if the box is a PPC or x86 or one of the Apple hygene products.
Micro-controllers seem to be the only hold out. Even coding on the Arduino you still have to know something about hardware to interface to the various boards.
Assembly? It really depends if you're writing a BIOS, writing virtual peripherals on the Prop, start-up/initialiation code, run-times for compilers. Or simply the joy of it. I like writing assembly on Z-80's and 68k/ColdFire. I wouldn't touch it on a x86, ARM or MIPS.
Programming Languages? They are really personal preference thing for non-professionals. I personally like Free Pascal, Oberon and BASIC. Mbed's online C++ compiler for ARM's micros is quite nice for hobbyists like myself.
Ada was not rejected by the programming community. It was rejected by the defense companies who saw it would dramatically reduce their profits. And they were quite right.
Of course there are many programming communities...
During Ada's brief period of fame the defence industry was a substantial part of the programming population. There were a lot less computers and a lot less programmers then.
Then there is the Windows world. No take up there. How come Windows is not written on Ada, or any of the millions of Windows applications?
Then there is the Apple world...same story.
Then the huge and sprawling conurbations of the Free and Open Source software world. How come Richard Stallman created a C compiler not an Ada compiler? How come Linus did not write the Linux kernel in Ada? What about all the thousands of programs that support the Linux/Unix infrastructure. No take up there either.
Is there even one program in common use that is written in Ada?
This all looks like a major rejection from all quarters of the "community".
So Ada is now confined to a small pockets of resistance hiding away in gehttos in places where normal people don't dare to go. It's still in use in an ever decreasing number of industries where it is perceived as offering the possibility of more robust and reliable software. Which is of course an illusion.
Don't be obtuse, Heater.
Ada could not be rejected from all quarters of the community because 95% of the programming community never knew much more about it than the name. Still don't, obviously.
Ada was a specific language for a specific purpose, and was very popular in the community for which it was intended. Of which I was a part at the time.
Nobody in their right minds would attempt to write a graphical operating system in Ada. Or a mobile phone app. Or a web site. Or a microwave oven controller.
But if you wanted a nuclear missile launch system, or a radar tracking system, or an air traffic control system, or a spacecraft navigation system, or a submarine combat system, then Ada could not be beat.
It was reliable, portable, and cheap - yes cheap. Sure, the compilers cost a lot initially, but the prices soon came down to where you could buy a fully validated compiler for the PC for a few hundred dollars - much less than you now pay for Micro$oft rubbish. And debugging and maintenance costs were massively reduced. And did you get that "validated" bit? That meant that code written for one compiler was guaranteed to run on any other - even if that compiler was written by a different company, and intended to run on different hardware. Unix, Windows, DOS, IBM Mainframe, various supercomputers, embedded chipsets, etc etc. No learning curve for programmers moving companies or hardware platforms.
Hardware manufacturers hated it. They could no longer sell you their "proprietary" languages written for their "proprietary" hardware. Whole projects could be migrated from IBM to VAX to PC by a simple recompile. And often were, if it proved that the hardware was not up to the task, or better and cheaper hardware came along.
Software manufacturers hated it. They could no longer count on lucrative "maintenance" contracts for software that was deliberately written in obscure languages so that no-one other than the original company could ever maintain or modify it.
Training companies hated it. The entire Ada LRM was smaller than your average "Dummies Guide to <insert your favorite dingbat language here>" book - and about a 10th the size of the equivalent documentation set required to learn to use C++ or Java effectively.
But many software engineers loved it - not least because having once learned it, their skills were applicable to just about every company in the industry. They could move at will anywhere they liked and be productive the day they arrived.
And so Ada had to go.
Ross.
We used Digital VAX machines running VMS and VT220 terminals, mostly.
(There was a few other machines, one of which allowed us to copy files from a PC-formatted 3.5" to the VAX)
The hall was always crowded...
Then a set of disks appeared With a PC/DOS Version of an ADA Compiler...
And suddenly the hall was half-empty.
There was as far as I know, ONE difference between the VAX and DOS Version Compilers.
The VAX Version didn't have a 'long integer'. This we solved by adding a single line of code that we commented away when compiling on a PC.
Those were the times...
I think I still have a copy of those bootleg disks somewhere...
The problem with computer languages is that they depend greatly on network effects. The C and C++ languages are not great and the anti-C/C++ camp have good arguments that I agree with. For example:
Why can't the compiler emit the header file?
Why am I constantly typing '!', '', '{', '}', '(', or ')'? This language is impossible to touch type because of an over reliance on characters accessed via the little fingers.
There are syntax landmines like the assignment within a conditional (e.g. "if (foo = bar)" instead of "if (foo == bar)") which create hard to find bugs.
The unchecked arrays may be fast, but enable buffer overflows which are the cause of many security flaws.
I flat out hated the language for a year, but eventually gave in. So why did C/C++ become so influential? The answer's simple, Unix was written in C, Unix included a C compiler, and Unix was the OS of choice in most C departments. So any company in the 80's looking to start a new software development had a pool of talent that knew C, while no one knew Ada.
tl;dr no one got fired for choosing C.
The new languages are flow-diagrams and graphical representations of state-machines... sad... (Rhapsody, I'm looking at you)
Your examples demonstrate what I am saying..assembly is needed and used when either inadequately hardware platforms are used or the project is cutting edge using hardware that is trying to accomplish the "impossible"...all at the expense of project schedule, project cost and future software maintainance.
FWIW..hardware is a small cost of a total project expenditure...software development and maintainance is much larger. Now whether a company adequately judges those costs is another matter.
One case I have seen repeatily is if a company favors (for a number of political reasons) a specific processor (i.e. Parallax mandating Propeller) there by forcing software to be Propeller specific...and thereby forcing "10 pounds of software into a 5 pounds of hardware"...and the subsequent need for assembly language. I have seen that business decision kill companies as they miss new project deadlines and not fix program bugs.
Again I have nothing against assembly language..it is just rarely the right choice for today's projects.