Slashdot Mirror
Ask Slashdot: "Real" Computer Scientists vs. Modern Curriculum?
An anonymous reader writes At work yesterday, I overheard a programmer explaining his perception of the quality of the most recent CS grads. In his opinion, CS students who primarily learn Java are inferior because they don't have to deal with memory management as they would if they used C. As a current CS student who's pursing a degree after 10 years of experience in the IT field, I have two questions for my fellow Slashdoters: "Is this a common concern with new CS grads?" and, if so, "What can I do to supplement my Java-oriented studies?"
Difference is the "real" ones have beards and wear suspenders.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
"Real Programmers don't use GC" is a mantra that is responsible for 90% at least of production bugs, together with "=" being typed instead of "==".
This is not a signature.
Shouldn't they be computer scientists? Software engineering, while related, is not the same thing as computer science. Would you ask a scientist to build a bridge, or an engineer?
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
Yes Java monkeys don't understand memory management.
But a CS student shouldn't be a simple Java monkey. C isn't good enough. They should all have at least a semester of Assembler.
There have always been a subset of CS students that didn't get anywhere close to the metal. They suck.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
There are different tracts in CS degrees, with some focusing on C++ and low level coding (embedded systems, OS, robotics, etc.) and others focusing on Java and other more abstract languages (automated reasoning, AI, NLP, web programming)...so I think it really depends on what the student choose to focus on.
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
Don't worry about it too much. Memory management is not that important for most people.
What you need to know is the process behind the memory management. You should be able to point to any line of code and understand exactly the process you are asking the computer to perform to execute it -- no matter how high level your language is. If you can do that, you'll be alright.
1. Yes.
2. Learn some lower level languages like assembler, C, or C++. Even if you don't use the techniques, understanding them will give you a better understanding of what's going on in your Java programs.
Learn some assembly. Not because you will use it every day (or ever) but because it helps remind you that all the code we typically write is just layers of abstraction on top of a machine (which even assembly is, albeit very low level abstractions).
An old boss from years ago (a mentor for me really) watched me troubleshooting a network issue in an application. He said to me "you seem to be having trouble spotting the problem. Have you tried going lower down the stack?". So I tried ping by name, nothing, ping by number, nothing, etc. Finally after reviewing ip configurations, arp and routing tables and probably a few other things I forget I figured out I had a bad cable.
That taught me a lesson that I've applied to many areas of computers, including programming, over the years. If something seems like it should work but does not maybe something underneath it is the problem. If you want to be able to debug code at the library level or interfaces to lower level languages it helps to understand things like memory layout, registers, the call stack, etc.
My $.02.
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
> CS students who primarily learn Java are inferior because they don't have to deal with memory management as they would if they used C
This is not "real" computer science. This is an implementation detail.
"Real" computer science is algorithms and data structures. Systems, networks, and software engineering. Languages and computational theory. AI and machine learning. Graphics and rendering.
Memory management is accidental complexity. We now have tools that manage it for us so that we can concentrate on the heart of the matter. He might as well be saying that CS grads aren't "real" because they use a compiler rather than writing machine code.
If you haven't learned how to minimize the size of your program to fit on an out-dated Apollo era mainframe, then you are not a computer scientist.
And don't get me started on those fools letting people drive a car without knowing how to drive a manual transmission.
Honey, where's my complain' pants? I got me some letters to write!
Times change. Not everyone uses the same systems. An education should be more about ways of thinking than about specific skills. Otherwise it it worthless.
excitingthingstodo.blogspot.com
http://www.catb.org/jargon/htm... A REAL programmer.
Well, in MY opinion, CS students who learned in C or C++ or Pascal or PL/1 are inferior because they use the stack as a crutch, instead of manually keeping track of callback history. If you don't have to write explicit code to keep track of every call, or allocate every local variable, your code will... well, actually, it'll likely be easier to read, easier to maintain, and easier to optimize. But it won't be as good as the code we had to write back in my day.
You know, I wouldn't want to specifically use the word 'inferior', but you do learn a hell of a lot from having to deal with your own memory management.
When I was in school, lo these many years ago, I and a fellow student wrote the same basic assignment for a course.
He was one of the sysadmins on the VAX and could set his process to use a vast array which was mostly empty, and rely purely on virtual memory. I had a tiny little 80286, and had to implement the same thing in a sparse array which took up a fraction of the space.
We both got the expected results and got good grades, but the prof basically said since I'd done so much more thought on memory management and the other guy didn't, I'd get the A+ and he got the A.
The Prof also stole my code to use in his own project, because by the time you accounted for architecture mine was about 4x faster and 100x smaller, and he'd basically given us an assignment which overlapped with his own research.
Would I want to do bare metal memory management in C every day? Probably not. Do I think it was valuable to have had to learn how to shoehorn something into a small amount of memory and explicitly be the one to make sure my memory wasn't leaking? Absolutely.
I think more modern software would suck less if developers didn't just assume there were massive gobs of memory sitting around, and implement everything in the easiest way possible without having to factor in resources. Most modern browsers seem to grow their memory usage at a pretty linear rate, even if you're not using the browser.
Because, really, pretty much every piece of software seems to double in it resource requirements every few years.
And understanding pointer arithmetic and semantics in C is valuable, even if most people will never directly see anything resembling a pointer these days.
Lost at C:>. Found at C.
It really depends on what you want to do. If you're trying to wring the last iota of performance out of an algorithm, then understanding TLB misses and cache protocols can be useful. Even accessing RAM can be an order of magnitude faster or slower, depending on what you do. So, maybe a class on microprocessor design?
OTOH, I find that an ability to understand functional programming, recursion and data structures is very useful. They're the sort of things I quiz people on when I'm looking for really strong developers.
Alan
In my totally completely unbiased opinion, I think that everyone should have a basic understanding of how computers actually work, from the ground up. A little bit of basic logic (and how that is implemented in hardware), introduction to low level programming (assembler) and using C to make hardware DO something. From there just keep moving on up until you get to Java. Learning operating system functions and why they are important (handling I/O devices, memory management, process and thread management, etc.). All that stuff helps you understand what you are doing, and potentially give you insight into how to debug it.
Nothing is more frustrating than arguing with someone about some computer bug/problem when their argument/explanation is provably impossible, based on how things actually WORK.
Computer Scientists understand the theory of computing. Software Engineers understand how to build software. Information Managmentstudent know how to apply computers to business problems. IMHO CS students are not prepared for real world coding applications. If you're going to program you don't need a CS degree, you just need a background in the programming language du jour. If you're going to solve difficult problems with a computer, you need a CS degree (theory, algorithms, heuristics). But to build a web site, ECPI is good enough. I don't think current CS curricula creates a solid programmer. However, many enterprising young CS students are already involved in external activities (open source projects, web site construction) and are learning the key skills on their own.
Feh. C. "Memory Management".
CS students taught in high-order language are completely deficient in their education. They haven't learned about opcode timing and instruction placement and hardware stack management.
If you aren't working exclusively in machine code, you're just a poser.
Welcome to the Panopticon. Used to be a prison, now it's your home.
I've recently watched my wife (C++ environment) deal with a new-grad (Java-based education.) It's true that pointers are a sticking point -- in the process of being taught Java, they get taught that pointers are bad and dangerous (all hail Java for solving the problem,) and can be made only barely tolerable by using auto_ptr, but really should just be avoided. Yeah, it's a problem, sure.
But the bigger problem we have with new-grads and junior-devs, in general, is the same problem you'd have in any field: they're green. They don't test well, or at all. They don't think designs through. They don't communicate well. They ask too many questions, or maybe worse, they ask too few. They try to fix things that aren't broken. They're bad at estimating task sizes (admittedly, people rarely get much better at that even after decades.) In an attempt to not suck, they reach out for best-practices and apply them zealously and inappropriately. They can't imagine how things will fail, or be abused. They spend too much time fixing small problems, and not enough time fixing big ones. And maybe worst of all, they're under the illusion that what they learned in school ought to prepare them for the workforce, when really it just gets their foot in the door.
We, as their seniors, are the ones that should be spending the time fixing their misconceptions, fleshing our their education, filling their minds with the horrors we've seen, and setting up their work habits. When they fail, it's because we fail to do these things, usually because we brought them in too late in a project, gave them too much responsibility, and are fighting a deadline. So we "just fix it" for them, and they don't learn from the experience, while we gain nothing in terms of productivity from having them.
But if I were to nitpick their education? Databases. Recent grads have little or no understanding of relational databases. Their thinking on organizing data, in general, is fuzzy at best, which impacts more than just database code, it impacts class and API designs, often crippling whole features with incorrect cardinality. It deserves more attention in school. The rest, we can fix in production. =)
One of my favorite Computer Science instructors said to us: Learn the fundamentals, and a hot button.
A hot button is the 'new cool thing' that everyone is asking for.
The fundamentals are, well, the fundamentals.
So, when I went to school to work on my Bachelor's, we used ADA, c, c++, x86 assembly. ADA was for the "intro to computer science", clang was for many, I chose to use c++ for compiler class. x86 assembly was for assembly language programming.
Back then Java was the new thing, so I made sure to take Java as an elective.
So for YOU, figure out what is hot, learn it, but also learn your fundamentals. Knowing how to allocate, use, and return system resources is a fundamental. That fundamental is used for working with Files, Memory, Databases. I would dare day that also learning to work with exception handling (c++/java) is a good fundamental. If you think 'old school' programming is an interest, then being comfortable with clang pointers would be good as well.
Uh, Linux geek since 1999.
The primary thing I notice about fresh Java school grads is that there's nothing in their resume that tells me they can tackle hard problems. No pointers. No lambda functions. No backtracking. No first-class continuations. All the stuff that used to weed out people in CS programs is gone; that means I have to do the weeding. At least Javascript has brought some of that back.
I remember learning a couple of assembly languages, 3 procedural languages, sql, lisp, and prolog during my undergrad CS degree, while learning three more languages including Forth, Basic, and SmallTalk in summer jobs around that time.
But in my recollection, particular programming language (details of) was not the main point of the majority of my CS (or EE elective) courses, especially not after first year. Quickly learning any programming language was just the price of admission to learning and practicing other CS knowledge. Computing general concepts, algorithm and database general concepts, intro to and practice with different styles of programming such as functional, declarative, procedural, particular types of applications as examples, cool AI'ish stuff, and a few things about software engineering practice, were much of the point.
So if your degree program is "about Java" and "experience with Java and an N-tier JEE stack", then RUN and take some MIT or Stanford online courses in more interesting and useful stuff!
Where are we going and why are we in a handbasket?
The department I go my masters in computer science from divided the discipline into three chunks:
systems
languages
theory
I think this is a good way to divide computer science.
It sounds like your Java / C question involves mostly languages, and a little bit about systems (since Java programmers do not need to have a fundamental understanding of memory works at a system's level.)
I don't think this question really addresses the underlying issue - what is computer science? To me, I tell people that my formal education is closer to applied mathematics than what I do on a day to day basis. I also like to humorously use the derogatory term "code monkey" to people that have learned everything through the "languages" chunk above. A lot of times when I've worked with these people, they haven't even really studied languages (Why did the language designers make the choice that they did? What does the formal language specification say the language should do in this case? How is this language related to earlier languages?)
Again, about 90% of what I do on a daily basis could be considered "code monkey" level. It's when a customer has a REALLY difficult math problem that my formal education comes into play, and for giving people confidence in me.
For your direct question, I'd study the book Computer Architecture, Fifth Edition: A Quantitative Approach (The Morgan Kaufmann Series in Computer Architecture and Design)
That's what I used, and it helped me understand a ton of memory management. Then again, my undergrad curriculum was based on C....
Many of the modern CS students spend all there time in a single environment and a single language (Java on Windows). If this is the case for your school they are doing you a disservice. I was exposed to the at least 5 operating systems and 7 or 8 programming languages and wrote assembly that ran on bare metal in school. If you experience a variety of environments and languages you will have a much better base to judge what is good and bad when developing solutions.
Everyone has a bias on what a true developer should be. You will not have the same interview for the same job title no matter what industry. Some managers will worry about how long it takes you to complete your work; Some managers will worry about the quality of work; If an architect interviews you they may care only about the design patterns you know; There is a Bias for everything. If your want to know a very low level language you need to know about memory management. If you want to use an abstracted language you should at least know it exists.
Yes, the concern is real and common. The antidote is building stuff. A bunch of stuff. The more stuff you build, the more likely it is you'll have to get "dirty" with the underlying guts of it, the more you'll know, and the more valuable you'll be.
For instance:
Of the many garbage collectors Java offers, have you ever used anything but the default? Do you have any idea what the trade-offs are and when you might want to use another one?
Have you ever profiled any Java code?
What do you know about Java byte code?
Ever SWIG wrap anything into Java?
Ever used Java serialization? Do you know what's wrong with it and why you wouldn't want to use it?
Custom class loaders?
My adivce: go learn everything there is to know about "something", it doesn't really matter what (maybe you want be the worlds foremost expert on malloc). In the process of gaining a very, very deep understanding of that 1 specific sliver; you're going to also learn about a ton of other stuff on the way.
C does offer the ability for explicit memory management and if thats what you want to learn I suggest picking up C. In programming the lessons are transferable and always useful when looking at another language. What you learn in C can be applied to what you do in Java.
That being said, Java does a lot of the heavy lifting in memory management, but it isn't fool proof. If its java you want to learn about, try running your jvm with less and less memory. This will make you conscious of the size of large objects and ways of getting around memory barriers. In java this really starts to apply when you are using huge data sets and repetitive tasks. Poorly written code will start to see oom and stack overflow errors. There are plenty of tools out there that will analyze memory usage of your code. I'd suggest getting some and trying to decrease your programs memory footprint without a loss in speed.
This, of course is all computer science, and has little to do with most software engineering done today. Knowing these things, though, will definitely put you leaps and bounds in front of other software engineers.
Brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants.
go out and buy another gig or two of ram for a few bucks.
seriously...its hard enough to find professionals to build software without getting bogged down with mallocs and leaks for god's sake.
when java first hit in the 90's, prettty much the #1 feature was its automated garbage collection...why now are we debating this now?
oh...i know why...its same group of old folks who live in the past and think anything not invented or produced 20 years ago is shit.
never bring a twinkie to a food fight.
CS is not a programming course. But a programming course or three is part of CS.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Computer science is no more about computers than astronomy is about telescopes.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Web development? Keep learning Java. You will rarely ever have to worry about memory management. Learning C won't make you a better Java programmer, and there are plenty of jobs for people with Java backgrounds. Of course, you should also know HTML/CSS etc. if you're going this route.
Video games? Learn C and C++, probably in that order. Java isn't going to cut it, you'll need to learn things like memory management and graphics programming. However, the object-oriented programming stuff you learn in a Java-centric curriculum will still be very helpful in C++ (or C# if you go in that direction), so you have a solid base to work with.
Embedded systems? You're in either the wrong school or the wrong major for that, you need to focus on C and Assembler for that. Completely different world from Java.
You get the idea. Figure out what you plan to do with your career if you don't already know (in a broad sense, you don't have to nail down a specific job), and steer your studies that way. If you want to keep your options open, teach yourself some basic C or C++ and see if it's right for you. If you can't figure out how to manage pointers, then you know what type of programming not to get into.
The problem isn't so much that new grads are missing some specific piece of technology or some specific piece of information. It's that new grads are typically missing, quite frankly, everything.
Programming and software engineering are -hard-. If you're a couple standard deviations above the average IQ, you can become barely passable in four years and reasonably good after ten. 'Reasonably good' is ideally the minimum standard that most companies would prefer to hire at, and the percentage of new grads which meet that standard is quite low.
Your best bets are two-fold: maintain one large personal/open source project for many years to demonstrate that you understand software engineering, and work on many smaller projects to gain diversity of experience. Optionally, you can pour your effort into the large project if it supports sufficiently diverse requirements. As an example, my large project was a mud server, which exposed me to everything from web server management, volunteer team building, and customer support to memory management, unix sockets, reference counting and coroutines.
In short, nothing substitutes for experience and breadth.
Alter Aeon Multiclass MUD - http://www.alteraeon.com
It is not which languages you know, languages are merely the means to express your computer science knowledge.
Do you want to go work somewhere and write Java programs for a living? Maybe you'd like to go write games or work on an office suite? Then learning high level languages like Java will serve you well. Do you want to write low level stuff and do "real" computer science? Maybe you want to develop a new high level language, or do hardware development or other significant development. If that's what you want to do, then you're right. High level Java and other languages should just be a footnote. Focus on Math, assembler, maybe some C/C++. Other low level work that provides a good foundation would also be wise.
Both of those are "Computer Science" disciplines in the modern sense. Obviously they are significantly different from each other in both required study and expected results.
and the Godheads sling opcodes. THIS is memory management, making all of your 1K count.
if this is supposed to be a new economy, how come they still want my old fashioned money?
I agree with the parent (@HornWumpus -- good name), but I'd like to elaborate.
First, I agree that "There have always been a subset of CS students that didn't get anywhere close to the metal. They suck.", and I agree that "C isn't good enough." No language is good enough by itself. If you haven't played with Functional, Procedural, Object-Oriented, and hardware-level (Assembler) languages by the time you've graduated, you've missed something.
You can figure it out no matter what they teach you, you just have to be inquisitive and ask good questions. You should take compiler, operating systems, and a numeric computing class which will each teach you about overflow and precision and memory allocation, in different ways, regardless of programming language used. You should have a basic understanding of how to do everything from scratch, with bare hardware, short of soldering the chip to a board (unless that's your thing, then go learn that too).
But then you should also learn that many "higher" languages make this easier... they have garbage collection built-in and you should learn why and when that's a good thing and why and when it's a bad thing. Java is good for some things, bad for others. If you go through a CS degree and all that you come out with is knowing one language, get your money back. Ask "why" early and often.
You should learn concepts and hands-on. You should learn the ideas so that, when a new language comes up next year, you can understand the literature about the pros and cons. But you should also be able to sit down with a couple of languages and pound out some simple algorithms and I/O with no references.
I liked my CS degree, but there were things missing. I had to learn network programming (TCP/IP, etc.) on my own. We didn't do embedded systems, so I didn't have much experience with small hardware and the nuances that come with them. But the advice I'd give is to avoid too many classes that are "just" programming, and focus on the fundamentals. Use as many languages as possible. Take Artificial Intelligence, Compiler design, Operating systems, data structures, numerical computing. Take a comparative languages class if one is offered. Take a database class. And take these all realizing that they're teaching you exactly the same thing -- how to solve problems using computers.
It's all ones and zeroes in the end. Once you've mastered pushing them around for one thing, you should be able to push them around for another, it just takes practice. Practice as many things as possible.
That's a bogus argument.
Real should be replaced with "Good". Are there "good" Javascript, Java, Visual Basic, etc., programmers? Yes there are always exceptionally gifted people -- however that is not the norm as those language encourages sloppy design principles. If programmers come from a C background they tend to be "better" programmers:
ALL good programmers understand TINSTAAFL. Namely,
* Floating Point
* Memory
* Pointers
* Budgets: CPU budgets, Memory budgets, Disk budgets, Network budgets, People budgets (such as programmer time vs machine time)
* Macro-optimization = Algorithm
* Micro-optimization = Assembly language
* GOOD programmers understand both the strengths and weakness of high level programming languages and low level programming languages. They are not married to the dogma of "one size fits all" -- they are aware that each language was designed to solve certain types of problems. They use the right tool for the right job.
I would also add unless you can read assembly language you're probably not as good as a programmer as you think you are.
I still maintain the "last good programmers" were those that could read 6502 assembly. Later generations are mostly clueless about the implementation costs.
I'd trust a programmer who's never dealt with the sorts of problems caused by manual memory allocation (or, even nastier, compiler bugs) about as much as I'd trust a plumber who's never gotten shit on his hands.
It's not that I think garbage collection is bad, but the sorts of bugs caused by memory stomping tend to be some weird non-deterministic stuff which makes you question your sanity and your tools. You have to learn to narrow things down as deep as possible, to trust nothing, question everything, abuse your tools, and occasionally go on some very strange side-trips.
Now, Java can lead you down some strange alleyways (concurrency, for example), but it doesn't even come close.
Log in or piss off.
I used to think I was a computer scientist, but now I'm not sure. Euclid? Diophantus? Babbage? Lovelace (albeit she'd be a founding mother)? Church? Goedel?
A Real Programmer
Jokes aside, i don't think Mel would get much work now. We're so far from doing that low level (for most things) that he'd spin his wheels for 2 days on a loop while real work needed to get done
The programmer you're referring to has a very narrow scope. Software development is big, and we don't all have the same problems. People are often very narrow in their view of the world, and assume THEIR view of the world and their problems are the only one that exists. Thus the C programmer who thinks that Java programmers are inferrior because they don't have to deal with memory management. (i.e. you don't feel our pain, so you're not one of us).
I can equally tell you that C programmers don't understand OO principles. If you don't do OO, that's fine. Just like if you don't need to deal with all the memory management issues, that's fine too.
Your programmer is just doing the same cultural bullshit that's been going on for decades "These kids these days aren't any good because they have/didn't-have BLAH-1. Back in MY day we had BLAH-2". 40 years ago (and outside of the software world) it was that doggone rock music.... "back in my day we appreciated Henry Miller, not these blasted Beatles and their long hair!"
People become attached to their view of the world and can't imagine it without it. This is the pitfall of age and experience.
AccountKiller
egads. i know a few gods. none of them write assembly or opcodes. they may write their own microcode compiler for the processor they're designing to solve what ails them, though :)
seriously, these are a few things i know most grad-student CS guys have never been exposed to but which should be taught:
. source code revision control systems
. debugging techniques (vs. broken hardware, not software)
. platform integration (e.g. where do i store preferences!?!?, etc)
. multi-programming in event-loop schemes
. techniques for gaining understanding of a large body of code, relatively quickly
. Makefiles/code build environs
. packaging
. testing, with large systems/moving parts.
i do device drivers so i don't often come across people who'd rather code in java. but the rest are widely applicable, i think.
If, like the vast majority of CS grads, your career is to write code for a standard/traditional software company, i.e. web, business apps, etc., then no, you don't need to know a lot about how a computer works. Your goal is to implement business decisions (i.e. write software that makes the business more efficient, more money, etc..) Anything that distracts you from implementing business code, such as memory allocation, vi/emacs, overly complex version control (*cough*git*cough*), "fringe" languages, and so on, is inefficient.
However, if you dislike being a code drone, or just happen to work in a career where scalability, parallelism, performance, and/or resource efficiency is paramount, then yes, you will appreciate a class in C, Assembly, or even an intro EE course that introduces you to IC chips and breadboxes.
On a side note, you will also appreciate taking a few business courses so that you can appreciate how differently business people speak and think from engineers. Heck, I would even recommend a few sociology, psychology, and/or history courses as well.
If the student's goals are to get a marketable career that will last at least until his next career, he needs to learn whatever employers will want him to know, not whatever is deemed the one true definition of computer science.
If the student's goals are to think and act like a computer scientist or a master engineer he needs to take the appropriate classes and gain the appropriate experience.
Anyone who wants to "think like a computer scientists studying memory management" should know and understand the memory management of not only assembler but also other languages that handle memory in other ways, such as traditional C or managed-memory languages like Java. They should also know how different hardware architectures present memory to applications - is the assembler code really running on the bare metal or is the microcode or hardware-virtualization-layer playing games behind your back?
Likewise, the student who wants to think like a master engineer needs to know enough to say "I will choose library A, compiler B, and run-time implementation C, middleware layer D, operating system E, and hardware F over others because together, they provide the best balance of speed, cost, maintenance, ease of programming, and other factors compared to competing products." For some applications, "knowing enough" means knowing enough about memory management to recognize when memory will be an issue that requires engineering attention/optimization and when it won't be an issue.
Here's a trivial example of how the passage of just two years from 1983 to 1985 changed the need to grok memory management:
In 1983, the early public release of MacPaint running on the early public release of MacOS is said to have used all but 384 bytes of the 128KB of the original Macintosh's RAM. Granted, it relied heavily on the routines that were in the original Mac's 64KB of ROM and it used its own spiritual analog of "disk-based memory" by storing most of the image on the floppy drive instead of in RAM. How did it do this? In addition to being written with a significant amount of assembly language code, it's my understanding that either MacPaint or the ROM routines or both used some very tight loops that, if memory were not so tight, would have been "unrolled" for the sake of speed. Today, or for that matter even 2 years later when RAM was relatively plentiful and cheap, a similar program could have been written in a high-level language without any fancy programming and without the need to "page out" the parts of the image that were not visible on the screen. The very task that required intimate knowledge of memory management in 1983 no longer required this knowledge in 1985.
Useful links:
* https://en.wikipedia.org/wiki/...
* http://www.computerhistory.org...
* https://en.wikipedia.org/wiki/...
* https://en.wikipedia.org/wiki/...
* https://en.wikipedia.org/wiki/...
* https://en.wikipedia.org/wiki/...
and links embedded in the pages listed above
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Wow could you please not downvote me please thanks? That's really rude.
Why don't you impose a $500 fine?
There are plenty of places where you can't just add more memory...embedded devices in particular. Your phone is limited to 2GB of RAM, and you really don't want any one app chewing it all up. Raspberry Pi, Arduino, BeagleBone, etc. are all relatively limited in terms of resources and to use them efficiently you need to be careful.
Even on really beefy virtualization hosts with a couple hundred GB of RAM, you want to be able to dedicate as much of the resources as possible to the guests, not the host management software--so you need to be able to put strict limits on how much memory the host itself will use under any circumstances.
As someone who has been in the field a long time now, I've learned not to judge programmer's talent so much on what they were taught or even what they're currently doing. It's how quickly they can pick up something new. And it's not alway about technology. It's also about being able to effectively grasp the subject matter that's the basis of the software you're developing.
My recommendation is to constantly challenge yourself to learn something new. If all your current CS work has been java based, then definitely it's time to expand beyond that, and not because there is anything wrong with java. I'd say the same thing if you had been using C++ instead.
To me you can make the same sort of argument about CS Grads never being exposed LISP/Scheme/Clojure. The problem is that a 4 year degree must include other things besides CS courses (which is good), but there is only so much time. You can't learn everything in 4 years which is why you must continue learning your entire career.
I'm willing to bet that the dude complaining about modern CS grads is woefully deficient themselves in some areas of CS that could they could really benefit from.
There's a difference between software engineering and CS. Dealing with freeing memory pointers is SE, not CS.
The problem I've seen in CS grads over the last 10-15 years is they have little to no engineering background (even when their degree is "Computer Engineering"). Most applications are complex systems. And most CS grads don't understand systems. I've been able to teach EEs, a chem E, a civil E, an MD and a CPA (among others) how to program. And they've had no trouble implementing solid class hierarchies and robust applications. It's much harder to teach a CS grad about structural integrity, analyzing a design for weaknesses, and root cause analysis. In some cases they won't accept those are even an issue since "software is so different from physical structures". So they keep building things that pass all the tests but repeatedly fall down once they get to production.
And hence the language is essentially irrelevant.
If it's actually CS more time will be spent on Turing machines and pushdown automaton than on C or Java anyway.
Those who can write in Java, and those who can write Java.
Or those who can write in C#, and those who can write the .NET runtime.
Or those who can write in PHP, and those who can create PHP. Wait, those are the same.
You get what I'm saying. The programmers who whine about requirements to understand low-level memory management are in the first category, and their knowledge and skills are laughable compared to the kind of programmers who get hired by the likes of Google, Apple, and Microsoft.
Stop trying to pretend you're as good. If you were as good you'd be doing something interesting instead of slapping together enterprise bloatware.
I think it's not just about memory management but more about understanding what's really going on in the CPU while your program is running, and memory management is just a part of that.
Some of this stuff is still very relevant today. If you want to understand how a buffer overflow exploit works you need to understand what's happening in your program at the level of bits and bytes in the processor.
It wouldn't hurt to take an assembly language course, preferably one that uses some small 8-bit processor. Nothing gives you an appreciation for the mountain of layers of software piled on top of the CPU these days like having to write your own function to divide two numbers.
Sweet explanation on the 'recent grad'.
I am guessing you (and your C++ wife) were programming equivalents of sliced bread when you started your career compared to the "unschooled" Java programmer.
Why is Java popular...its good enough for most of the tasks and reasonably competent people can write non-scary code.
Not every programmer needs to understand "bit bashing" and a mental model of computers at the assembly level. Its an overkill.
Tat Tvam Asi
First, if people learn C they can not do memory management either. When Bertram Meyer propagated is programming language Eiffel (basically a mix between C++ and Ada) he introduced a linker level/global code optimizer that also chose 'the right' garbage collection algorithm for this particular program and linked it (from a set of about a dozen).
He made many studies comparing (relatively simple) Eiffel programs with C counterparts. The Eiffel programs where on average 30% faster, regarding memory management, and all but one of the C programs had memory bugs.
There will be plenty of posts that claim if you learn C and assembly (probably C++) that will make you a better programmer. Unfortunately it is a fallacy. C is just a portable (macro) assembler, nothing fancy about it except the pitfalls. You can make pissing contents all night long in a pub about niche problems in C and pointing out how smart you are (which does absolutely not save you from making mistakes exactly in those areas ... giving you smart comments next pissing contest when you are again in the pub and admit your failures). In C++ that would be even worth, frankly I forgot more about C++ in the last 20 years than the average /. will ever know anout it, I don't really miss it. However my next job is in C++ again, will be funny. Programming in assembler is even more fruitless as there are not many interesting processors out there where it makes sense to program in Assembler, no one programs a Sparc or an (modern) X86 in Assembler ... 68k systems or ARMs, that would make sense. Would you learn anything relevant for: .Net / C# ...
Perl
Python
PHP
Prolog
Pascal/Modula (2)/ Oberon
Lisp/Scheme/CLOS
Smalltalk
Basic (regardless which)
Java
Erlang
Haskell
Miranda
ML/OCaML
Fortran
Forth
SQL
???
Nope. Absolutely nothing. If you learn assembler you learn how that particular processor works. If you learn C you already have learned: how a particular processor works, is irrelevant.
If you learn C/C++ the only thing beyond memory management you might learn is: there are resources even more scarce than memory, e.g. file handles/sockets. And: you will fail for 4 to 5 years on doing memory management 'correct'. Afterwards some guru will tell you, that your code is 'quite correct' but you don't do it 'right'. And after 30 or 40 years programming in C/C++ you still will have memory related bugs in YOUR code or in code of your TEAM. Murphies law: if something can go wrong, it will go wrong (sometimes).
To become a better programmer only two things are interesting: broaden your horizon, that means look into requirements engineering, architectures, processes, audits/reviews, technologies, tools; and different paradigms: learn a true OO language, learn a language with life images (Smalltalk, Self, Newspeak), learn a functional language (Erlang, Lisp, Haskell) or slightly mixed paradigm languages like OCaML or Miranda. Learn logic based languages like Prolog. ... or learn hacking LLVM ... hm, or how is that other C++ meta programming suit named? Forgot it ... anyone has an idea?
If you are into it, even learn C++ and how to mimic functional and logic programming with functor objects and operator overloading, but be adviced and use a GC library for C++
Oh, you could of course learn specification languages like Z or compiler specification languages like ENBF and based on that Yacc/JavaCC or ANTLR (compiler construction tools).
There are in fact things you can learn if you do learn Assembler. E.g. on an 68k you could access memory byte wise, word wise and long word wise (8, 16, 32 bit words).
A guy once claimed to get fast graphics you have to do it in assembler. He wrote a Brezenheim algorithm for black and white graphics for Macs (something around 1992) see:
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I'm doing a lot of programming interviews these days, and I can tell you that it really doesn't matter.
During interviews I couldn't care less about pointers: I will check problem solving skills, I will assess how they react to existing code they are not familiar with (this is the real challenge you face when getting a new job). I will use good old FizzBuzz test, I will play with basic recursion (insane how most candidates will fail at even the most basic recursive logic). None of this is language specific.
C developers might also be lacking notion of proper data abstraction and will scatter global variables all over the place. This is as bad (if not worse). And believe me, most C developers don't understand memory management neither (is this virtual memory? is this page committed or just reserved in the address space? how comes you get an out of memory in your process and yet you still have tons of free physical memory? what is heap fragmentation? is malloc slow? is it thread-safe? what are heap protection canaries?) A lot of C developers will be using static data with constant size in order to avoid dynamic memory allocation. The result? Java developers are typically more versed in dynamic structures such as double linked lists than C developers...
And by the way, Java has "pointers", we just call them references, and any Java developer worth working with knows the difference between a value-type (int) and a pointer (Integer), they just have different names, you can't assign arbitrary values to your references and you don't need to free them explicitly, that's all.
Low-level programming is a specialist issue. Maybe it's time to turn C programming over to people with real EE degrees, or who can at least use an oscilloscope and wire up an Arduino. At the application level, who has time to manage memory by hand any more? EEs and mechatronics people, and OS and compiler developers, need to learn C, but most application programmers today do not.
The emphasis on Java isn't unreasonable. The pure-interpreter languages (Python, Perl) are too slow for large server-side operations. (If it's 3x as slow, you may need 3x as many server racks. That costs.) Java is memory-safe and goes reasonably fast. Go may become an alternative, but it's a little too weird to go mainstream yet. C++ has turned out to be a mess. It adds hiding to C without adding memory safety, an unfortunate feature combination unique to C++.
Realistically, a CS degree today needs to cover machine learning, which is all about calculus and matrix math. There's less need for discrite math and bit-pushing.
I have classic CS training - all that stuff in vol. 1 of Knuth, automata theory, optimization of logic gates, formal methods, proof of correctness, etc. It's just not that useful any more. Mostly I write Python and Javascript.
A big problem is that they learn everything they know in relation to only one language. They should be using more than one throughout their education so that they properly generalize the principles. Personally I think Python is a good choice because it supports a variety of programming styles from procedural to functional. It has a number of features that are either missing or clunky in Java. On the flip side, Java's strong typing is a good contrast to Python's duck typing.
Another issue is that CS is treated as if it was an engineering program when it really isn't anything of the sort. As a result, the recent CS grad will have little to no knowledge of maintainability or making code to be genuinely reusable. They will know little to nothing about designing an API that can be lived with years later.
So you're asking - is the quality of the programmer determined by ability to write in lower level languages? Well, then I'd have to say the answer is a resounding "no". Having an understanding of the machine and how modern languages came to be is extremely useful, but managing memory yourself without a clear reason (such as limitations at the hardware level where optimal performance matters) has no purpose but to supplement the egos of the programmers involved. It is a question of mental prowess - not skill as a programmer. It is roughly equivalent to asking someone to rub their belly and pat their head at the same time. There are those of us who do better with managing complexity, and we can deem them "smarter" or "possessing more intellect" if you like. If that's you, then congratulations for you. You're more capable than others at this. Bet you can't write in straight binary! Languages like Java exist for the same reason programming languages in general do - to lessen the burden on the human mind and allow us to concentrate on the real problems instead of the machine problems. Playing "how low can you go" is a childish game.
So, you "I'm the real programmer because I program in C" types... tell me, how will having to handle memory management and all the crufty bits help you when you get a real work problem, and deal with a bunch of users who really don't know what they want their system to do, or you have to deal with management who have no idea what IT can do. When your requirements keep changing, but the deadline can't shift. When you have to take a poorly written system, and adapt it to the new business environment - but you don't have the time, budget or resources to rewrite from scratch. Get your collective heads out of your "this is what real programming is" arsehole. Thirty years ago, the same was said about people who programmed in BASIC or COBOL vs those who coded in Fortran or Assembler. You're just a bunch of irrelevant elitist snobs.
The acronym STEM breaks down into Science, Technology, Engineering, and Mathematics; and this is a good way of categorizing the different kinds of learning that lie behind really knowing computer science and other STEM disciplines.
A "computer science" degree at an accredited 4-year college should cover topics related to computer science in all four of these areas:
Science: The science behind the technology, including chemistry and physics necessary to implement the technology that is used to build computational devices
Technology: Hardware and software technologies, including: logic gates, CPUs, memory (primary and secondary), communications interfaces, operating systems, compilers, databases, programming languages, etc.
Engineering: techniques for analyzing problems and engineering solutions to those problems (using software, typically)
Mathematics: binary math, formal logic, formal language theory, etc.
All of these together provide the grounding to enable the student, after matriculation, to go forth and do good things. As with all disciplines, the better prepared the student, the more deliberate the graduate's approach to solving problems and being productive.
I have an aquaintance who was (by her own admission and grades) fairly poor at her CS studies, but who was exposed to lots of core computer science STEM material in college. She is now an excellent practitioner/manager in a software development position. She is often frustrated by the plethora of "programmers" (both young and old) who didn't get exposed to the full range of computer science material. They don't know how to think about different ways to solve problems, or what the machine is doing, or how their code is translated into lower level instructions, and this limits their ability. Using tools at a higher level of abstraction is absolutely essential for achieving modern rates of productivity in programming (i.e., Java instead of assembler) but doing so without an understanding and appreciation of what your tools are doing for you is like running a race with blinders on.
Applying for a job that has a larger programming component than I am used to...
When I went to school I learned on, Pascal, C, COBOL, Assembly, VB...
Position will likely want someone with Java. While I have dabbled in some Javascript using Google Maps API, I'm not exactly current on it.
On the other hand DB is what I do, and SQL is probably the scripting I use the most these days.
Anyway I have done some training on Python, but most of my languages are pretty antiquated by today's standards which I am wondering if it will diminish my chances. Here is hoping more emphasis is placed on analysis and not on initial coding.
Most companies aren't interested in you recreating the wheel, they want you to get a working, maintainable product out the door in as little time as possible. Design patterns are more important to focus on than memory management these days.
C and C++ have their uses, but at the end of the day, C is little more than a macro-assembler and is completely inappropriate for most tasks in the business world. I've never worked anywhere where the C/C++ side of the project (there's always one group of holdouts) isn't consistently the long pole in the tent. After seeing several projects fail over this, I'd rather they "keep it real" on their own time.
Yeah, well I'm sick of people learning CS in C. They don't know about manually managing the stack like they would if they'd learned in assembly.
So, you are arguing that only being exposed to one environment is fine? I didn't mention anything about real or good. I just said if your school is only exposing you to a single environment and language, then the school is doing you a disservice.
I'm no fan of Java-based curricula, for the same reason I'd be no fan of Fortran-based curricula. Computing isn't about one language. Each language and system shows you one hyperplane of a vast multidimensional space. The best programmers know lots of languages, and choose wisely among them — or even create new ones when appropriate.
In the production world, there are times where some C++ or Java code is appropriate ... and there are times when what you want is a couple of lines of shellscript and some pipes ... and there are times when the most sensible algorithm for something can't be neatly expressed in a language like C++ or Java, and really requires something like Common Lisp or Haskell. If you need to exploit multiple processors without getting bogged down in locking bullshit and race conditions, you're much better off using Go than Java.
(Just last night, at a meetup, I was talking with two bright young physicists who reported that their universities don't do a good enough job of teaching Fortran, which is the language they actually need to do their job. Scientific computing still relies heavily on Fortran, Matlab, and other languages well removed from what's trendy in the CS department — no matter if that CS department is in the Java, Haskell, or Python camp. But if you want to learn to write good Fortran, you basically need a mentor in the physics department with time to teach you.)
And there are times when the right thing to do is to create a new language, whether a domain-specific language or a new approach on general-purpose computing. There's a good reason Rob Pike came up with Sawzall, a logs-analysis DSL that compiles to arbitrarily parallel mapreduces; and then Go, a C-like systems language with a rocket engine of concurrency built in.
(And there's a good reason a lot of people adopting Go have been coming not from the C++/Java camps that the Go developers expected, but from Python and Ruby: because Go gives you the raw speed of a concurrent and native-compiled language, plus libraries designed by actual engineers, without a lot of the verbose bullshit of C++ or Java. Would I recommend Go as a first language? I'm not so sure about that ....)
What would an optimal computing curriculum look like? I have no freakin' clue. It would have to cover particular basics — variable binding, iteration, recursion, sequencing, data structures, libraries and APIs, concurrency — no matter what the language. But it can't leave its students thinking that one language is Intuitive and the other ones are Just Gratuitously Weird ... and that's too much of what I see from young programmers in industry today.
"What can I do to supplement my Java-oriented studies?"
Learn C. Learn C++. Learn Assembly. On the other end of the spectrum: Learn LISP. Learn Prolog. Learn learn learn.
BTW, I heartily agree that Java should be a second-year type of language. "Now that you know all about pointers and how to use them to make the data structures we discussed in CS 190, we'll let the computer handle memory management so we can focus on algorithms."
Those grads are merely inferior for tasks where memory management is paramount, that's all. Just like someone who graduated with a database class would be inferior for database programming. It doesn't make them inferior all around. Java is just easier to teach AND learn with, really.
I remember doing all these exercises in C about storing multiple "strings" in the same character array. Most programming jobs out there wouldn't deign themselves to be concerned with such low-level solution-space details. Even when I had to deal with "packed arrays" in C++, Java, and JavaScript, the first thing I did was write a class around it to abstract all those details away.
"Love heals scars love left." -- Henry Rollins
Much that is taught in CS today I had to learn on my own because it hadn't matured enough yet to be incorporated into CS programs: multi-threading, unit testing, OOP, SQL, data mining, all of the web technologies, etc.
But perhaps today's graduates will be complaining ten years hence how new graduates just rely on quantum computing searches and don't know anything about pruning search trees.
Seriously, though, to the point, I'd be more leery of those who graduated ten years ago and had not kept up their skills as opposed to those who graduated recently and did not learn skills from ten years ago.
learn C and an architecture, then you can go back to the more abstract languages and all that cool CS stuff. If you want to do it at that point.
Java programmers (at least those writing non-trivial code) do need to understand memory management, in particular how Java manages memory, and how they can influence the JVM so that what it does is appropriate for the problem under consideration.
How this is a CS issue I have no idea.
After 10 years in IT, you should already have a good answer to your own question. If you don't, you may already be too far behind the curve. Look at your peers; in particular, look at what the successful ones know that the others don't.
You should understand how computers work. You should understand how systems talk to each other. You should understand how to communicate what you want to the computer. The more of this you do, in fact, know, the better off you'll be in the future. Try to learn it ALL; you won't, but the closer you get the better off you'll be.
Of course, when you start getting close enough to stand out, either you'll be running your own company successfully, or you'll be wondering why those whippersnappers around you are waiting for you to fall over dead. Whatever you do, don't spend your money just because you have it. Either gamble big and win (i.e., get the Big Bucks for designing and building the Next Big Thing) or save carefully so that you won't be depending on Social Security (or the current equivalent when you get that far) to pay for your food, clothing, and shelter.
what about just the classes needed to work so you have to take 4+ years of student loans.
I say all you really should need is 1-3 years PURE class room.
I would add 68k to the 6502 :)
However ARM is mot and either, in fact it is simple and straight forward.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
CS students who primarily learn Java are inferior because they don't have to deal with memory management as they would if they used C.
This is snobbery at its best. Pay attention in computer architecture class, you will be fine.
In my opinion, education is not about how to do something immediately useful, but primarily about learning to learn. Vocational schools may be different, but that's why they are generally frowned upon — I wish, universities weren't teaching with Java exactly because it is in such wide use in the industry today.
While studying, learn to use a language (or two), which you aren't likely to encounter at any future workplace. Pascal. Lisp. Fortran — whatever. That will still teach you to learn things and force you to learn again, when you are hired. Not only will you be more adaptable to future changes in fashion, you'll also have the awareness of how various problems are solved in different languages — making you a better programmer every day.
In Soviet Washington the swamp drains you.
Object? What's an object?
Where are we going and why are we in a handbasket?
At the best undergraduate CS departments, the students have to learn the basics of C, assembly, Java or some other high level programming language, plus some elementary algorithms and data structures.. that's before the end of sophomore year. I know in my school they learned some Lisp, C, assembly, and Java in the basic courses.
i'm amazed at how much Computer Science and Network Engineering (or telecommunications) overlap.
I did an MS in Information & Communication Science and part of our required coursework was to get a CCNA. They integrated the Cisco coursework and test into their own stuff. It really boosted their hire rate for graduates b/c anyone w/ a CCNA can find work somewhere.
We did alot of stuff in signal processing and encoding that is very similar to the 'bit twiddling' you guys are talking about. Headers, flags, etc its all there...we used stuff like Dijkstra's algorithm but not to the same complexity as CS.
The craziest stuff we did was beamforming & satellite stuff...that was fun
Thank you Dave Raggett
everything not in bold is a question of networking and internet coding and graphic design
facebook needs all those engineers to mine our data & make it available to outside parties
**i am impressed** with how facebook.com's scalability and speed, I don't deny it at all...but like I said, alot of what makes www.facebook.com "facebook" is just basic transfer of images and text with alot of interface layers as to harvest data...
Thank you Dave Raggett
Do you think Ayrton Senna knew what kind of thermodynamic happens in the engine? (No)
Would he have been a better racer, if he knew? (No)
I am a programmer, but I have a Mechanical Engineering degree. Everything I learned in school after the age of 14 is inapplicable to writing businnes applications. I do not need to know how C works, because I do not work with C. For 99.9% percent of business applications written in Java, C does not matter. If you want to learn, great, do it. But most likely it will not benefit you in any other way than you can look down on those who did not learn it.
Most of the math you learn after multiplication will not come up in 99% of programming jobs. Learn how the Java garbage collector works if you use Java, but HASKELL/Lisp/C++ is just a nicety, like Spanish or cooking.
When I got my CS degree I had to learn FORTRAN, COBOL, Pascal, Ada, C, and three different varieties of assembler 6052, 80386, and VAX.
I need to buy some suspenders.
Hey Timothy, have you ever noticed that submenu over on the left of the front page? You know, the one that lists the various sections that you can posts stories to? Ever notice that there is one called "Ask Slashdot", which just happens to match up exactly with the premise of this story, not to mention the title. Why don't you do all of us who filter by section a favor and try posting "Ask Slashdot" stories to the "Ask Slashdot" section every once in a while? Thanks
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
Doesn't matter much which one, just learn to so some even trivial things in assembler. Then understand *this* is reality, and everything else is an abstraction.
For bonus points, then do it in hex without the benefit of an assembler to translate mnemonics into opcodes and calculate your relative addresses.
but gawddamn, if I meet ONE more unshaven skinny ratty-haired white dev/programmer in his late twenties/early thirties with an aversion to water, soap, matching colors and food (what is it with devs and eating disorders???) here in Seattle, I might just have to defenestrate the fucker to save my sanity. Preferably out an upper window at the downtown Macy's, so that said dev/programmer might actually observe cleanliness and fashion through visual osmosis prior to becoming one with pavement. I don't care if said beautiful mind is autistic, aspie, or what-not--Hygiene is source code!!!!!! Execute it on a daily basis! And if the sensory stimulus is THAT much of an overload then spend some of your six figure salary to get therapy and coaching on how to minimize input while maximizing the ability to incorporate the close proximity of other people!!! I much prefer the Indian and Chinese devs and programmers, not least because they don't have eating disorders and they both understand and practice a minimal standard of hygiene.
Here's to hot beer, cold women, and Glaswegian kisses for all.
I am going to add to this, especially since self teaching myself both Scala and Groovy. i came from a school that Introduction to Programming was taught using C and the basics of functional programming. The next classes focused on OOP and started with C++ but eventually the head of the CS department was a Java advocate and everything got switched over to that focus. And they focused too much on the OOP and not enough on the benefits of functional programming. So my anecdote is: There are those that write OOP code and those that write functional code. Not to say that those that write functional code don't know how to write OOS code, they just know how to make their code better and more efficient than those that focus on just the object oriented aspect of it. I do believe that if more students nowadays focus on learning functional programming, and this is possible with Java, we wouldn't see the problems with software and memory bloat. With the proper mix of OOP and Functional Programming you can let 'GC' do its thing and it will be efficient and sufficient.
I'm a hiring manager. Not knowing low level absolutely counts against you in terms of breadth of knowledge. It generally isn't a deal breaker but it would be treated the same way as not knowing OS theory, not knowing database theory, not understanding algorithms design, or machine learning. Its a hole, you lose a few points and we move on with the interview. As far as it being common CS grads differ a great deal from school to school, the curriculum is not remotely uniform. A recent CS grad can vary tremendously in what they know and what areas the degree doesn't mean anything than they've had some classes in some computer stuff.
In terms of what you can do to supplement. Learn things unlike Java. Definitely at least one functional language and one procedural language so you have something other than OO programming. Learn a low level language and a very high level language. Languages can do double duty so for example Mathematica is very high level and functional while C or Assembler (better choice BTW) is low level and procedural.
Not Babbage or Lovelace I wouldn't think... too practical :-)
Church and Turing, perhaps; the functional programmers can follow the former and the procedural ones the latter. I'd probably also include Claude Shannon.
Write a compiler.
I don't think everyone needs to learn C, however I think it is important to try to understand at least the level below where you are working. If you are working in Java, learn how the Java runtime behaves. Learn how the Java compiler interacts with different code constructs to produce different bytecode. Learn how the Java libraries implement their various functions so that you understand their underlying behavior and possible performance implications. Most of my work these days is done in C#, and while 90% of the time I don't have to worry about all the underlying details, knowing them is invaluable the other 10% of the time.
While I did learn Assembly (MIPS and SPARC), C, and C++ in school rather than Java, I don't think those low level things actually had a significant impact on my job coming out of college. You don't need to understand how C allocates memory if you are not working in C. You do need to know how the environment you are working in allocates memory though, even if that behavior is hidden from superficial inspection.
Because back in the day we were disparaged as engineers and not real computer scientists if we worried about memory and addressing things at the processor level. Real computer scientists apparently used things like Modula-2 and then Java instead of that messy C and FORTRAN that only lowly engineers like myself should touch.
I actually noticed this trend about 8 years ago, and wrote a book to solve it. The book is called Programming from the Ground Up. It is a Linux-based assembly language book, but also teaches a lot about systems programming in general, but without being too technical.
For the other CS-oriented stuff that they don't teach, the two books you should get are how to design programs and Structure and Interpretation of Computer Programs. After that, I have written a series of articles to apply those ideas to "real" programming languages on IBM's developerWorks. You can find links to them here.
Engineering and the Ultimate
The things you list are excellent. Without understanding basic pitfalls and trade-offs, no amount of MIPS or RAM can save you.
6502 was very limiting; I'm grateful that we have cheap micros that can do 30 MIPS instead of 0.5 MIPS. So whole new classes of problems can be solved in real-time. But embedded programming is still a place were bytes and number of instructions are a big deal.
It boggles my mind how inconsiderate programmers have become where a news webpage can bring a multi-GHz 64 bit CPU to its knees.
High Schools are offering "college in the classroom" programs today. I think it reflects poorly on both that they can fill so much "wasted time" in high school with low level college courses which have degraded to the point of being near the more difficult end of high school curriculum.
If your mommy can bitch to your professor about your progress or grades, IT IS NOT COLLEGE!
Meanwhile we have high school kids entering who are so poorly prepared that the remedial courses are overloaded.
The culture is shifting and I do not think it has anything to do with embracing modern education "technology." First off, university is for the motivated - if you can't be serious then you shouldn't waste the money. I've even had people allude to the "A for effort" type reasoning... Also, I've had people who complain something was on an exam that wasn't covered in lecture! (As if there is an unspoken rule.) Homework IS required people!! Most students don't realize the reason 12 credits is FULL TIME is because the total time required is the same as a 40 hour per week job. So then I have to hear sob stories about how they have a full time job and 8-12 credits of coursework. You simply can't condense the same experience into that much less time, humans have not evolved, and education psychology has made little progress (something which I dabble in because I do make an extra effort to be effective.)
There is a great deal of pressure on staff to not flunk too many people or upset the "customer" too much-- as the admin brings in more high paid MBA types to tell us how the world is a business and their hammer experts are worth the high fees. Too many fear that it reflects badly upon them and you'd think a bunch of smart people would realize correlation is not causation (besides it takes more than 1 whole group flunking to even begin to do correlations.) No curve, if they all suck they must all flunk; it is the only way a quality standard is maintained.
Allowing the current behavior and culture continue will gradually produce worse results as the bar slowly lowers due to student pressure... It's like an evolutionary pressure... This is one area where "the market" should be forbidden because those forces lead to trite certifications by correspondence school (and we have such great respect for those... once we put "cloud" or "online" into the marketing.)
Speaking of which, the classroom has degraded to the point that students have no clue what a real functional classroom looks like... and the profs are not much better themselves. Most the tech encourages what is wrong with education today. Oddly, like how cell phones seem to have make people more distant than bring them together (in general. Sure I can email somebody far away but it also means I don't bother to see people next door because I can email them instead.)
End of rant. There are so many issues one could do a series of books.
Democracy Now! - uncensored, anti-establishment news
Ideally, for most high level applications, the programmer doesn't have to use a programming language that forces him or her to do manual memory management. The programmer can use a language like Python or Java where memory management happens in the background. And that is how it's supposed to be. There are more relevant problems to deal with.
Now, on the other hand, let's say that the project is writing some sort of device driver or real time software. Perhaps something operating close to the 'core' and in an environment with limited resources. Then that programmer will have to use a language like C or C++ and do their own memory management.
It's a good thing that we have an education system that produces both these types of programmers. However, I think that most programmers, during their career, learn to do both these types of programming. For me: I started out programming in C/C++ and I've since moved on to Python and Java, because that's the kind of projects that I usually get these days. Now, if someone hired me to work on an application that required tight resource management. Well, then I would use C/C++ and do memory management myself
Unless you're targeting an embedded system with resource constraints, I see no reason not to implement it similar to the above.
It's straightforward. You're unlikely to introduce any bit-twiddling bugs. It wouldn't take more than a few minutes to write and debug. And, most importantly, it's readable for people who aren't accustomed to bitwise operations.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
I studied CS in the 80s. The first language was LISP. I don't think we were taught any language that required explicit memory management. We did learn, of course, how a computer works from the silicon level and up. On the other hand, it was impossible to do anything without learning C, so we learned C.
Core memory was just coming down from $1/bit to $0.10/bit, and it would be $0.01/bit soon. Tape was (and still is) king for bulk offline data.
Keeping down memory usage and getting LOTS of functionality for each cycle and byte was paramount.
Cobol programmers (replace with Fortran, C, C++, Java, Easyout, RPG, APL, RPG II, Snobol, etc, etc) programmers weren't concerned unless they hit a 'wall'. The wall that assembler geeks hit every day. So unless you write assembly and poop core dumps, you aren't a 'real programmer', ... back in the day.
Fast forward to today. We whine of only 32G on our phone that has more processing power than mainframes of yore. We use 90+% of computing power on 'human interface issues' rather than addressing the problem being solved. Programmers do program without ever knowing what the hardware is let alone how it works (even to the digital level, let alone electronics - the discussion that ALL ELECTRONICS IS ANALOG is an argument for another day).
IMHO, this is not all bad. It does turn out programmers that don't think of limitations, they just drive to possibilities (that is a good thing). Embedded systems geeks are the new low level programmers (programming closer to the metal) than most programmers today.
Not all CompSci 'professionals' are scientists. I have a CS degree from 30+ years ago. I am more of a programmer, and long ago gave up bemoaning the 'real' programmer wars. But not all programmers do, or should, program at all levels (hardware wise). Micro-controller and embedded device programmers are doing more with less than ever. Smaller and cheaper electronics make that possible. Uber-power CPUs and cheap memory allow programmers at higher levels to not worry about those resources.
Todays 'restrictions' seem to have more to do with the 'size of your pipe to the internet' and the amount of super-fast-bulk-storage you can get use effectively. From my old days, hainveg 16T of data in my hall closet that I waste space on just to watch yet another episode of a time wasting TV show is unthinkable. Having more CPU power in my android phone than on my desktop or laptop seems odd too.
What I find scary is how we are 'surprised' when an 'enemy' slips in a few hundred thousand more transistors onto chips we have them build internet routers with and don't even recognize it for a long time. (You can do the looking up the articles on why the NSA, DOD, CIA, and other TLA organizations are not using some routers coming from China and other places.). We ignore the details of the resources (equipment, fuels, etc) we use because we want it fast and cheap.
But I digress. We don't need as many 'real computer scientists' as we are generating degrees for. We need more systems analysts, designers, and coders. We will have, and need SOME computer scientists. They do the esoteric research, blaze trails that I can't begin to imagine. I am sure there is a modern day Lady Ada, Bool, Babbage, Touring, etc out there. We all don't need to be them, but we do need some REAL explorers in the field that do more than play video games and build internet toasters.
... "When you pry the source from my cold dead hands."
If you take a computer architectures class and KNOW how memory works, who flipping cares. Truth is, much like nobody programs in assembly any more, all modern languages have garbage collection and most have eliminated pointers. Why? Well the reasons are many. First off, such techniques are error prone at best. Even IF someone understands them, sometimes things get overlooked and when they do, they are hard to debug. The reality is that the OO paradigm and in the near future functional models will be 99% of what the overage programmer will be exposed to. I'd rather hire someone who was comfortable with these concepts then someone who could map put and manage their own memory any day of the week.
As far as I'm aware, any university level CS (now dubbed computer studies and not science) has a required module where you learn processor logic down to the flip-flops, you make machine code in an emulator and you make your own "OS" which is really just a string processor that can interleave the strings as if they were tasks.
To get through CS you need to at least see this stuff and achieve a 60 or higher. Sure, the language they teach you abstract data types has changed over the years. When I started it was Pascal in the intro course and standard C in the abstract data type courses. Then C++ in the object oriented courses until midway through my studies they switched over to Java for things like the machine learning and simulations courses. Generally you could use whichever languages you wanted for your submitted work, however.
That said, I was always surprised by the skill-level of people who were able to temporarily remember the material for said courses but who could not grok it for the life of them. Usually, I hope, these were people from other majors who wandered into a CS course to fulfil a requirement. I shudder to think that some of them intended this as a career.
If you go to college and all you learn is Java when you got your CS then your an idiot. I got my degree in Math, taught myself C, avoided Fortran like it was Ebola (it is in Software terms, not wait, that's Forth). Anyway, Software is Art. It isn't science, it isn't Engineering. It is Art. It should be taught like Painting, only with Math and to Nerds, and Geeks, and people with severe social problems who are way too smart.
The thing is, that the people who are good at this, really good, are so good that you will never, no matter how much you work at it, be as good as they are. They are gods. I've been doing this for twenty five years and I'm good, I'm slow but I am good. But I have seen really good, I have seen artists who are like Rembrandt, these guys like Linus Torvulds (never met him but you know his work) these guys come along and they just kiss the canvas and they change our lives. They pretend that they are writing software but they are creating art.
The rest of us do that to, and most of us are pretty good, we invent languages, and rules, and say stupid things like, "if you don't get close to the machine for a semester then you aren't a real Computer Scientist". And then we expect that other people will just follow along.
In the end the things that makes you a computer scientist, a software engineer, a computer programmer, an engineer, a mad scientist, a developer, they are all pretty much the same things. You know what tools you need to do your job. You work to get those tools. You don't bitch about it if you can't get them, or you leave, and in the end. You write software that works. That is it. You write software that works. You want to be a Computer Scientist? Can you write software?
Beware the wood elf!!!
Memory management isn't taught so much these days because, what in the hell are you going to write that's going to use 16GB of RAM?
In all seriousness though, memory management was important when software and hardware were on par with one another. However, (IMO) hardware has outpaced software at this point. I defy you to find a program my gaming PC can't run whilst I simultaneously play Crysis and browse Slashdot. In addition, most high level languages are incredibly forgiving when it comes to bad memory management, thanks to good built-in garbage collection. Sure, it helps to know that grittier low level, less abstracted stuff. Knowing what your computer is doing on that level would make you exceptionally efficient. However, if you are an experienced programmer, who understands best practice and can competently scour an API for the most efficient classes and methods to use in your object oriented programming, I see no reason why you shouldn't be seen as a "real" programmer. Anyone who says otherwise needs to get with the times...
If you only program on Windows then you are write. Welcome, however to the real world where windows is but a very small fraction of the hardware devices in existence and the very vast majority of them do in fact require memory management to function. Bad Advice is in the end Bad Advice.
Funny thing about games even, it turns out that if you were writing games even on Xbox you would find that your employer would fire you with that advice. You should keep it to yourself.
Beware the wood elf!!!
I'd recommend a class in assembler language. It's sufficiently nuts and bolts to reveal the nature of the computing world.
Read "Structure and Interpretation of Computer Programs" by Abelson & Sussman (http://mitpress.mit.edu/sicp/) and "The Art of Assembly Language Programming" by Hyde (http://www.plantation-productions.com/Webster/www.artofasm.com/index.html). Do at least some of the exercises. Bask in the knowledge that the Java that makes up your peers' sole exposure to the art and science of programming is a mere corner case in the coherent universe of Turing-complete symbol systems. (Recommendations from my idiosyncratic experience, obvs.)
A programming language is just a tool. Don't focus on the tools so much. To me, real CS is algorithm design and data structure design, both theory and application to real and imagined problems.
It contains submitted questions and responses. The question titles alone will give you an interesting perspective on what a computer scientist is. There are few questions that have anything to do with software development or programming. That corresponds to my experience as a former faculty member in the CMU Computer Science Dept., and to my experience since then working with computer scientists.
But there is an important distinction that was not raised in the question: almost all the computer scientists I have known have Ph.D.'s in computer science, and mostly do research (which may or may not involve software much less programming).
Doug Jensen
Coming from a strong C background and now working mainly as an architect closely with devs in c# I bemoan their lack of understanding of how memory, SQL, caches or networks really work. If you are making highly scalable systems (as we are) it is important to understand how a single line of linq can cause major memory churn, or that entity framework is terrible at certain things or the fact network latency matters, or your fancy cache is actually making it run slower. The key is to measure everything using something like statsd and graphite/grafana. Then poor performing code will clearly show up and the devs learn the error of their ways and improve. We all need to keep learning, don't just blindly rely on some new fancy framework to solve issues; think about it and become better
EEs need to know the basics of electrical theory. Even if they use design tools that handle all the low level details, to do a good job and avoid mistakes they need to know simple things like Ohm's law. No one says "that's too low level, the state of the art has made Ohm's law only useful to a small set of professionals."
The low level tools of CS are languages and interfaces. A professional needs to have knowledge of both high level and low level tools. If they don't their training is inadequate. Even if the exposure is in school, and not used professionally, it's important to have the experience.
By the way, so called Software Engineering is a bad joke. It is almost non-existent. Real engineers, like ME or EE or Civil Engineer types can design something for a predictable cost that has a very high likelihood of meeting all it's design goals. If the cost, time or result is wrong it's because someone failed. By that criteria all software development is always a failure. Using the term "Software Engineer" is fraudulent. Other engineering disciplines should stop computer software developers from degrading the term Engineer.
Why is Snark Required?
I know lots of computer scientists--which to me means requires they have a Ph.D. in computer science from a good school--and their needs to write software vary all over the map, depending on the kind and amount of computer science (=research) they are doing. But all of them understand at least the Ph.D. level principles of software science, plus a decent amount of software engineering too. Some of my computer scientist colleagues are fabulous programmers and others are stopped at the competency level they needed to get their Ph.D.'s.
Doug Jensen