I am entering university next month and have some exemption exams today. One of which is Computer Organization: things like Boolean Algebra, Gates (AND, OR, NOT etc), Assembly Language are taught. I wonder why learn such low level stuff. Does it benefit me as a programmer, likely developing in much higher level languages like C#, Python, PHP etc?
|
|
Software is an ever-changing field. Some of what is hot today might and will be forgotten till the time you graduate. Definitely concentrate on practical skills in popular languages like C# / Java / PHP. Then study more 'hot' languages like Ruby, F#, Clojure. Assembly Language while almost obsolete in 99% of the areas where software is used, will give you a unique perspective of the low level workings of your system. Assembly is not that hard actually, and is a fun thing to brag about. My colleagues are usually impressed when I tell them I have been doing machine code on 8bit computers (I didn't have an assembler). |
|||||||||
|
|
Learning programming from the bottom up is invaluable. You will use boolean algebra practically every day as a programmer. Reducing truth-tables to minimal logical expressions and doing equivalent transformations of boolean expressions comes in very handy. For example, when writing code, sometimes it's more natural to write something as:
If you know your equivalences, you would know that it might be clearer to write:
When you're examining code, you'll be able to quickly and easily tell if all cases are handled through complex As for assembly and (basic) circuit design, this may not be something that you ever use. However, think about what it is that we do. We take high level specifications and break them down into smaller and smaller bits and build up a program of specific steps which will, in the end, act according to the specification. By learning assembly and simple circuits, you bring this decomposition down to its lowest level. It is an excellent mental exercise that will (1) force you to think about what it means to work through a problem step by step, clock cycle by clock cycle; (2) make you appreciate all that is going on under-the-hood while using higher level languages; and (3) give you the understanding necessary when you have to get the maximum amount of performance out of a piece of code. You will not be sitting at your desk performing boolean algebra problems to hand in to your boss, nor will you be hand coding a web site in assembler. But the skills that each of these exercises teach you will come in handy every single day. |
|||
|
|
|
||||
|
|
|
You will understand the machine you are working with. As a Martial Artist needs to know his muscles and which diet is good for him. You will have to make many decisions and in some cases this may be the question if it's a good idea to implement some feature in a high level language or if you need to write it in a low level language to avoid performance problems. Even if you won't be able to implement it in Assembly yourself, because you specialized in something else, yo should know the differences so you know when it makes sense to hire somebody to do this kind of work. If you work in high level languages you will benefit from knowing what's going on behind the scenes, how for example a map, a vector or a linked list is implemented and where are the advantages or disadvantages. And in general it is just another way to train your ability in abstract thinking. It doesn't matter that much if you train this i Assembly or in Python. |
|||
|
|
|
I concur with what several others have already said. You won't be sitting at your desk doing boolean algebra exercises, nor is it likely that you will start out at a job where you are tasked with coding something in assembler. But the big advantage to having some grasp on these very basic concepts is that you will have a much better understanding of how computers work, and how the code you write is actually transformed into machine code (by the compiler and/or JITter) and executed by the processor. This understanding will help you consider how the code you write is likely to perform. And, as for assembler specifically, device driver development and such things all aside, every once in a while, even though I mostly work on C#/ASP.NET web applications at present, I have been thrown into the debugger with nothing more than a disassembly listing. Having some idea how to read it is a huge benefit in such situations. You don't have to understand all the nitty-gritty details, but recognizing the assembly (or IL, in the case of .NET) code corresponding to common high-level-language constructs can really help you deduce whether the problem is actually there, or farther up the call stack. This is particularly common when you are working with third-party libraries for which the source code is not available. For example, taking x86 Intel syntax assembly, if you're looking at the disassembly of a stack frame and seeing an I have toyed with Intel assembly language programming on my own, as well as did some Motorola assembly development in school. The useful take-away from that hasn't been the knowledge of the language itself (I almost certainly could not write anything non-trivial in assembly language as it is), but the understanding of how the computer works, and the ability to read at least basic assembler language code and make heads and tails out of it. |
|||
|
|
|
I asked myself those same questions when I started to study Software engineering two years ago. Learning boolean algebra, assembly language and others low level stuff is not necessary for every day work you will have to do at your job because you won't use theses knowledge often in high level language. But, programming is mainly about how to organise data and control the flow of execution of your programs, optimize your memory and the speed of your algorithm. You can't learn properly how to do those stuff in high level language because of the abstraction made over the data(everything is simplefied for you). Don't get me wrong, abstraction ain't a bad thing at all, because it help you to be much more productive in many ways. By contrast, programming in assembly language take an eternity... In conclusion, learning low level stuff allow you to have a better understanding of what is going under the code you are writing in high level languages. This can make a huge difference between a good and a bad programmer. |
|||
|
|
|
I think it never hurts to answer questions starting with "should I learn" and a subject inside your domains (remember - there are always two domains: programmer's and user's) with yes. There is only a question of prioritizing what to learn first and what next. |
|||
|
|
|
High-level languages provide abstractions for the low-level stuff, and most of the time, you won't have to think about the low-level implementation when you write high-level code. However, at some inevitable point, the abstraction will leak, and you will need your low-level knowledge to troubleshoot (and solve) the problem. Here's nice reading on the matter: http://www.joelonsoftware.com/articles/LeakyAbstractions.html |
|||
|
|
|
Boolean algebra is a pretty good fundamental to have. Digital electronics (logic-gate-level circuit design for small circuits) is a good way of training the application of boolean algebra. If it's more of an "introduction to assembly language", it certainly will not harm you, knowing how the actual hardware deals with stuff. If you think it's trivial nonsense, why are you going for a degree in the first place? |
|||
|
|