It really just depends on what level you are writing at. If you plan to operate at user level, then you don't need it. If you plan to get closer to the hardware, then it will be useful.

doubt I'll ever be writing drivers or anything

although I would love to write some software that interfaces with analog signals from drum triggers >.<

You could say this about almost everything. But every programmer needs to know something that most programmers don't need to know. If you don't know anything beyond "what most programmers need to know" you'd know practically nothing. Also,

http://www.joelonsoftware.com/articl...vaSchools.html

Beyond what candybar is saying, I would also argue it's fairly useful to understand the low level storage requirements of various basic datatypes, as well as to understand how more complex data types actually work at the low level, when you are trying to build a bigger systems and subtle high level choices might have fairly large impacts on how much memory something takes or how fast it can run. Or in database design.

Wrong mindset. You should be wondering what nifty things you could do with that knowledge and tinker around not file it as "yeah whoteva"

normally when they introduce new concepts, I try to think, Okay, what are the applications for this? Example: dynamic arrays. I was happy to finally be able to do something I didn't understand why it was possible before.

Counter-point: dynamic variables. I totally get why a dynamic array is necessary, but other than just being the other side of the dynamic coin I don't see when dynamic variables would be use. Rather, I don't get what they can do that automatic variables don't do.

Same thing applies here. Sure, I don't know a whole lot yet, so perhaps that's part of it. But im not sure of specific uses for knowing that kinda stuff for memory locations, which is why I asked.

You may never be in a situation where you need to manipulate pointers explicitly, but aurely you can understand how it's useful to understand how memory is stored and accessed, as a programmer.

If you think pointers or recursion are hard wait till you play Diablo II in Hell Untwinked.

I completely disagree that it's necessary for the vast majority of programmers to know how things are stored in memory. Is it necessary for me to know how, say, the .NET garbage collector works? Because I don't. Should I know what the instruction set is of the CPU I happen to be using? The whole point of software engineering is to abstract away things that aren't necessary, this goes for knowledge ass well as code. In my experience "it's important for programmers to know X" is said by people who grew up in a time when it was important to know that and aren't willing to acknowledge that their knowledge is now useless.

The concept of what a pointer is and how it works absolutely has to be understood, even in languages (like .NET languages) that gloss over it. For instance, if you look at C# documentation, it says that by default, all function parameters are passed by value. In VB.NET you are even forced to add the "ByVal" keyword to every parameter. However, consider these three C# functions:

public void Increment(int i) {
i++;
}

public void Derpify(List<string> list) {
list.Add("Derp");
}

public void Derpify(List<string> list) {
list = new List<string>();
list.Add("Derp");
}

The effect of these on the parameter in any code that calls them is, respectively: 1) nothing 2) "Derp" is added to the list 3) nothing. This is because object variables in .NET actually represent pointers and that - not the object - is what is "passed by value". But value types, like int, really are passed by value. There's no way of predicting or understanding this behaviour without knowing what a pointer is and how it works.

After you spend a few months trying to fix memory leaks in an enterprise CRM application with a .NET client, you will :P

Find everything that implements IDisposable, make sure they get Disposed, profit? :P

Short of bugs in .NET, isn't that about it? I'm guessing "bugs in .NET" is probably what you're talking about.

What you are learning now is a foundation for higher thought. Don't confuse abstractions of code with abstractions of design.

More or less. Even though it should work the way you are saying (well, plus cleaning up delegates and event handlers properly), but there are a lot of wrinkles.

There are lots of .NET standard library classes that are thin wrappers around unmanaged code and don't implement IDisposable well. We also were using a convoluted design for managing 3rd party addins (it was Microsoft's design :P) and because of the way it managed things across app domains it was very finicky and not very well documented, and not based on IDisposable at all.

edit: oh yeah, I forgot about large object heap fragmentation, which is easily the most annoying

This is generally my position as well.

Although I think its important that students learn some things to a pretty deep level, even if those specific things aren't super useful to the majority of programmers. It serves at least two purposes (and probably more):

1. It exposes students to completely different areas/concepts of CS that they might not have been that aware of but that they might find very interesting.

2. It makes people better programmers. Learning and understanding complex concepts is important. In real life you often have to dig deeper into something you don't know much about and that isn't useful for the majority of other programmers. It's good to get practice with that.

Edit: #2 is kind of what Joel Spolsky was getting at in that quote above by candybar, my problem with it is that it explains how learning pointers can be useful but doesn't really talk about why that's the best way or why its better than other potential topics.

Concepts like pointers and recursion are base programming concepts that help train the mind to think in CS terms. The same can't be said for, say, learning Assembly, or learning how compilers work, or various other indignities that were foisted on me in my CS degree.

I generally don't have a problem with students being taught concepts, as opposed to specifics. I do think that CS is currently almost entirely a trade, like engineering, and not an academic discipline, like physics or pure mathematics. I disagree with Spolsky that "pointers and recursion" are hard concepts, they are just a bit unintuitive. The answer to producing good CS grads is not to hammer those concepts into them but to give them real world experience earlier in their degrees and see if they can cope.

How compilers work is really useful! There's a whole class of parsing/grammar problems that you encounter in lots of different places that can be solved with the concepts you learn from a compilers course.

Assembly falls into the "Let's expose students to different aspects of CS" bucket for me.

But I totally know what you're saying. I was also lucky to go to a University that had a really strong co-op program so by the time I graduated with my degree I had two full years of actual work experience.

Visual Basic came out in 1991 and most of the people here are in their 20's and 30's. You don't worry about these things much in COBOL or SQL either. You could be 60 with a 30+ year career in software development and not know much about low-level details.

On the other hand, there are tons of 20-something engineers who work on embedded software, real-time trading systems, operating system kernels or performance-sensitive applications for whom intimate knowledge of low-level details is essential. After all, for you not to worry about this, someone else has to do. So this idea that knowledge of low-level details were once important, but not any more is rather fallacious, unless you want to take this discussion a few decades back.

You're getting hung up on the word "necessary" here but I already answered this:

Candybar, I missed that last quote of yours about "you'd know practically nothing". Well said.

This and a thousand times this. Patterns you learn from implementing a compiler occur over and over again in high-level application design.

To be fair, a modern CS curriculum spends what, like 3 weeks on assembly? That seems completely reasonable. I also think ChrisV is extrapolating too far from his own job. Not every programming job is insulated from having to deal with low-level details. To insulate you and others who work largely at the application-level from low-level details, people who work on operating systems, device drivers, database engines, application servers, web browsers, compilers, interpreters, system libraries, language libraries, concurrency frameworks, etc, spend a lot of time worrying about low-level details.

It's like saying, no one needs to know how to make cupcakes because everyone can just buy it from the bakery. Well, at some point, somebody has to do the work.

There's some things you shouldn't abstract away. A web programmer who doesn't know how HTTP works is about the same as a general programmer that doesn't know how memory management works.

Abstracting away basic knowledge of security is causing all kinds of trouble these days for example.

Why do I even need to know stuff about searching and sorting or algorithms in general if there's libraries for that (which should be used in most cases and trying to roll your own will end up sucking).

The list goes on.

candybar nails it as usual.

clown, while i mostly agree with you personally, i think some of these examples you're presenting as obvious wins for the "you do need to know low level stuff" are actually begging the question. especially the sorting algorithms one -- i think for many professional programmers it would be perfectly reasonable to hold the position you're presenting as absurd (i think). it really depends on what your goals are and what you want to get out of programming. but i think chrisV is right that it's possible to be a productive web or ios programmer, eg, earning a good salary, without ever knowing about the implementation details of sorting algorithms, and with knowing very little about memory management, registers, etc.

the other side of this coin, the one that continues to strike me, is how many people who *do* know quite a lot about low level programming and computer hardware know so little about what makes readable code or maintainable high level system design. i've believe for a while and continue to believe that is the most difficult part of programming.

Ugh. Programming is such an emotional Rollercoaster. I was so pumped am hour ago after finding and fixing a bug that had been plaguing us for a while. Now i come to find out that the business side prefers the "broken" version

Tell them to put in a feature request.

I recently led a small project and I had the hardest time figuring out if I thought a certain bug was actually a feature.

What really didn't help is I had just gotten stoned (I got the alert at night) and I have the hardest time making firm opinions when high.

All this discussion of what you need to know and not reminds me of this post http://jangosteve.com/post/380926251...t-theyre-doing

Lets be honest, we are humans and we have a limited life time on this place called earth. Not everyone is going to know the minute details of programming. However, I think the biggest thing is being aware of those low level details is important. At the very least, you know your limits and at least appreciate the tools that we have that keeps us away from these small stuff like how memory and pointers work.

On the contrary it would be really ignorant to complete turn the away and not learn stuff like this when given the opportunity. However I do not think that is what anyone is advocating that stance here.

But then again, it really depends on what field you work in.