You should definitely put those things you did in your own time in there as well. When I did that (and I did way more in my own time, as a hobby, than in real IT jobs), I got my perfect job.
Blog: "If you don't know how compilers work, then you don't know how computers work"
- Thread starter Farid
- Start date
Very well put. The blog writer has some valid points, but goes waaay over the top with his conclusion.
Funnily enough, the parser part of my compiler building uni course was the only one I found really interesting, and which was really useful for me in later times. (The worst was code generation which was mostly wrangling with the horrible tools they forced us to use, some self-written stuff based on burg with next to no documentation...)
I very much agree. Understanding of programming language logic and inplementation is very important to someone who wants to be a good programmer. I was shocked to discover that many informatics students in my university, while programming in Java, have absolutely no idea how object-oriented programming works, not speaking about it's history or similar. Also, I believe that every programmer should constantly "look behing the edge", learning new programming languages and styles (functional, aspect-oriented usw.).
P.S. I haven't read teh blog, my comment is only about some statements found in this thread
P.S. I haven't read teh blog, my comment is only about some statements found in this thread
I don't know... of course I would like all CS graduates know everything from assembly to compilers. At least when I was in my school days compiler and programming language courses are still mandatory. So is assembly.
What happens now I am not sure. Last time I've heard they are teaching Java instead of C/C++. Maybe that's the "future." However, sometimes it's annoying when you have to explain very hard to someone how buffer overflow exploit works.
What happens now I am not sure. Last time I've heard they are teaching Java instead of C/C++. Maybe that's the "future." However, sometimes it's annoying when you have to explain very hard to someone how buffer overflow exploit works.
itsmydamnation
Veteran
I dont know at what level your talking about, I have no programming skills ( i have used perl a lot) and even i have a general idea of how a buffer overflow works. The fact that someone can come out of 3-4 years of study doesn't is a bit scary.
im a network guy so maybe stairing at packet headers half the day helps in these regards
I'm amazed that someone can write "staring at packet headers half the day" and "helps" in the same sentence.im a network guy so maybe stairing at packet headers half the day helps in these regards
PellePlutt
Newcomer
I'd say the problem is that learning about stuff like compilers (or theoretical computer science btw) is only beneficial to a certain type of student. Reading a book about compilers, getting some working knowledge and passing an exam doesn't help anything. In order to gain something, you need to get a deep enough understanding to be able to apply what you've learned in a different context.
Most people are simply better off learning what they'll be doing anyway: programming in a high-level language.
Most people are simply better off learning what they'll be doing anyway: programming in a high-level language.
I'm not sure that's cause and effect in the right order. Maybe it's just those who have the skills and talent for high level architecture who try themselves at large assembly code bases.
I suspect students wouldn't actually see much larger codebases if they were taught assembly instead of high-level languages.
I can understand teaching Java early because you can learn all about object oriented theory without having to worry about pointers, segmentation faults and buffer overflows.
I think most CS programs still get you into C/C++ and assembly later on. At least they do in all the universities/colleges where I live. They tend to stick with Java for the most part because you can build applications with GUIs rapidly, which is a little more in line with a four month course with bi-weekly assignments.
I worked with different assembly languages prior to working with high-level. While the basic understanding of the architecture can be important for producing better optimized code, the difference nowadays is almost negligable. My opinion is that noone needs assembly nowadays bare the drivers writers.
I think having an assembly course is a good idea, just so you understanding of the program counter, the stack, registers, memory and how a processor performs instructions. The vast majority of people will probably never program in assembly again, but it's good to have an idea of how things work.
At the driver level (in terms of writing a few library functions called from, say, C), but knowing assembler can be useful at times for higher level work even if you don't write actual assembly code. For example, it can be handy when you are producing an optimised program/library when after profiling and choosing the best algorithm, you need to work out why your code is still too slow. Setting the compiler to output assembler and looking at what it has produced can give you valuable clues on how to re-write the high-level language to allow the compiler to do a better job.
I think a BSc. computer course should the whole range of programming levels with, perhaps, starting in the middle (C/Pascal) and expanding in both directions.
See, that's pretty cool. We never even touched profiling when I was in school, but I've looked at it on my own time and used it for a few applications. Only with Java though. If I'd had the option of course that covered that sort of material, I definitely would have taken it. If I'd gone to University, it may have been an option.
Around my parts it seems like you do a lot of C/C++ if you study computer engineering and a lot of Java if you study computer science. Both give you the opportunity to study other languages. I'm just not sure that it's mandatory.
If I'd gone the University route I could have studied functional programming languages and all kinds of good stuff.
Most of the people I'm talking about are self taught, and whatever Assembler would have been the first language they wrote "large" apps in. And like me they've probably written literally millions of lines of assembler.
The Advantage of assembler as a teching tool IMO is that the scalability issues with software happen at much smaller sizes, a 10K line assembler program can be a mailntenance nightmare if you don't plan it. It takes 100's of thousands of lines of C/C++ to get in the same mess.
But as I say it's just been my experience.
Yes and you get to understand why certain types of structure work and other don't.
Most C++/Java only programmers don't have a solid understanding of when to Inherit and when to Agregate. They seem to assume the language does the organizing, they don't build well defined interfaces and they don't really define what their "classes" are responsible for and more importantly not resposible for.
Obviously this isn't true of all engineers, you can learn all the same organisational/structural lessons just programming in Java/C++, but you don't really start paying for the mistakes until you have a LOT of lines of code, so a lot of people never learn the lessons. And because many of these codebases live for years people looking at them simply assume it's the way you do things, so the patterns tend to persist.
Now we're miles off topic, since the original article is about understanding what the machine is doing to execute your code. Random on topic note, I doubt more than 20% of programmers in the games industry today could profile a piece of code and do anything but algorithmic optimisations on it. 10 (maybe 15) years ago that would have been closet to 100%.
It's like this: in Belgium, parents have always teached their children how to drive a car. And it works, more or less. Although many foreigners think Belgian people are bad drivers, they actually do pretty well, all in all. They just do it all in a different way.
While with formal schooling, you can at least require that all people learn the same things. They might not learn them all as well, and the creative people might have to find sideways, but the overall result is generally pretty good and predictable.
So, the question becomes: what end result do we want, and how do we teach them that?
Similar threads
