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.
Although I would feel ashamed if I didn't know how to manually manage memory (or how computers encode things, for another shocking example of something that not all CS graduates know), but computer science is not a programming course. The hard problems are not solved by knowing a particular language, be it low or high level. You can manage memory flawlessly and "crash" with an out of memory error if you don't develop your algorithms with memory complexity in mind.
Take heart: real computer science has nothing whatsoever to do with programming in any language.
It's the old and recursive old-young thing. Really, if you learned programming with C, you never had to take care of finding a room and high voltage for the computer, or repairing the paper slip feeder.
Now that computer pervade everything, I guess the remaining constant in CS is "understand problems in a way that lets you find a technical solution".
Cheers
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
Was this programmer by any chance an old fart? Because C is a good fit for computers and applications from 30 years ago.
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
we code with assembly, fortran and cobol
C is for these lazy kids
A real CS degree involves a lot of math and learning how to design algorithms. They learn how computers work and what rules and laws they follow. They are *computer* *scientists*, not programmers, not IT specialists, not hardware engineers (though the last one helps a lot).
That said, most CS programs now-a-days suck, even as code-monkey schools. They do not teach you how to code, they teach you how to use tools A, B, and C to accomplish a given set of tasks. If they are faced with a problem outside of that range, or that requires a different tool, then they are lost. Because they have not learned how to program in general. (Many grads these days never learned how to learn, which is a superset of this problem.)
Tell me, have you ever written a web-app from scratch? Even something as simple as a hit counter.
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.
Extensive experience in C (and to a lesser extent C++) is generally indicative of a much more solid understanding of how low-level software systems work. Most of the real theoretical computer scientists I know, incidentally, aren't particularly strong in this area. Computer engineers usually have a lot more experience with it.
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. =)
know--or at least familiar with the concept of--what is even COMPUTATIONALLY POSSIBLE. THAT is computer science, as in the science of computing or what is computable. It progresses to things like how actual computers work, leading into things like memory management, assembly, building a compiler. Also, real computer scientists know who the fucking founding father of the discipline is.
Why web monkey body shops these days demand a strong CS background is beyond me. Sure they're smart and do real, hard work, but the idea that you should have a computer science background to work for them is preposterously offensive.
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?
Every so often I macro-expand Lisp macros (loops are very entertaining). While it's not bare metal, it reminds one that at root there's always a goto statement somewhere.
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.
There's no such thing as "Real Programming"
http://www.eggwall.com/2014/05/theres-no-such-thing-as-real-programming.html
Posting anonymous to avoid Karma whoring.
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.
Please allow me to be very snobby and arrogant.
I think to focus on either camp is to miss the whole point of "Computer Science", and focus on "Computer Programming" instead. With my CS degree, we had to focus on math, combinations, algorithm analysis, language theory, parsing, OS design, complexity theory, etc...
I think the difference between one language and other is a scalar difference, while the difference between "just programming" and all the theory is an exponential difference. The latter stretches the mind and gives us more mental tools (macros) when attacking a problem in real life many years after the degree. Furthermore, it's perhaps easier to learn a new language on your own, but it's much more difficult to learn (or to motivate yourself to go and learn) about language theory, for example.
On a separate note, the C vs Java comparison can be flipped, one could criticize C/ASM/Binary programmers as not having enough experience with OOP design. Again, same poop, different pile.
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.
When I was in college, Java did not exist. Take your script kiddie language and make Flappy Bird clones with it. Real programmers learn Assembly and C.
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
Wow could you please not downvote me please thanks? That's really rude.
http://i.cubeupload.com/T6cyLu.png
It is not which languages you know, languages are merely the means to express your computer science knowledge.
Yes, and nowadays that is a Java course, which doesn't teach you manual memory management (but if it doesn't totally suck explains how garbage collection works). The point is that CS isn't vocational training for code monkeys. The important problems need to be solved at a higher level.
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.
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.
Picking up programming if it still interests you.
You probably have also heard this gem from the same person... "Java is unfit as a programming language because it uses too much memory" (with no attempt at even defining what amount is too much)...
Java is just capable enough to do almost any task, and just universal enough to run on just about any CPU architecture. If you are OK with your career in computer science being confined to "almost any task" and "almost every architecture" then stay the course. If you are concerned that you won't feel fulfilled until your career takes you to "every task" and "every architecture" then stay a little longer and learn more bare metal topics.
But make no mistake, any toolbag that discredits Java without specific reasons (besides the aforementioned "its a resource hogG!!!!!11a") is worth about two fucking nothings.
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?
Buy a microcontroller and its associated programmer/debugger, program something non-trivial to run on it in assembly.
I would not just make this about Java or C. To me the problem is that newer students start at such a high level that they do not appreciate or understand what the tools do for them or how the automation works. If you don't understand memory management, or variable scope, or how to write space/time efficient code, what the compiler does for you, how code is optimized, the way an actual HTTP request is communicated/served by the webserver, or how a GUI widget is actually implemented, then when it does not work you will have NO way to debug or even understand where to start looking. Automation and abstraction layers and higher level languages are great at helping to be more efficient, but if you don't understand enough of how the basics work, you will always be dependent on people who know how it works and therefore less valuable to your employer.
If you want to augment your skills to be a better employee (coming from a hiring manager), learn C, read a book on operating systems, write a windows GUI program using C, learn to program in bash. There are good books and even on-line tutorials and become familiar enough to write these, and the couple of weeks of time, might not be enough to take that "C" coding job, but will for sure put you head and shoulders over your competition in that first job and earn you much respect with the more experienced team members.
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.
Looks like I have a unique experience here. When I took CS 10+ years ago in my final year they switched from C++ to Java. The reason being that Microsoft that year, in their infinite wisdom, stopped giving universities a deal on Visual Studio and other MS products. The university responded with dropping C++ from the curriculum and switching to Java. Fortunately for people like me in their last year _most_ professors allowed the students to submit assignments in either language.
So this taught me one thing, a hatred for Java right down to my bones. Taking 4th year classes and doing 4th year assignments in a new (and yes it was pretty new at that time) language took so much more time. Java was a slow kludgy pos as anyone who suffered though the browsers of the day with their horrific java plugins knows.
But I do know this, I think they dropped some of the lower level programming classes when Java came along. You know, the ones dealing with pointers, balancing a red-black tree, etc etc. I don't know if knowing this stuff made me a better programmer or not but I know I hate Java.
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
One has to never stop learning to go far in the systems development world.
Programming:
1. Learn assembly language - specifically how to maintain data on a stack, heap and static data segments.
2. Learn an old programming language like FORTRAN and understand what FORTRAN looks like in assembly language.
3. Learn some straight jacket language like Java and why it is for anal retentive project managers who think you need training wheels.
4. Learn a strongly typed language like C++ so you can understand how to apply software engineering discipline to your projects and why!
5. Learn C and Perl because you need to write some code quickly and with freedom.
6. Learn Python and Ruby because languages like these are the future.
7. Algorithms!
Software Engineering:
1. Design patterns!
2. Never reinvent the wheel!
3. Understand how good design in development can save lots of time in maintenance later.
4. Understand the multilayer cake of a software system: data, middleware, business rules, presentation layer
Systems Engineering:
1. Hardware
2. Firmware
3. Software
4. How to partition system requirements among all three to save time and to increase reliability.
5. System of Systems approach!
Half the "programmers" never open another computer science book after graduation.
Keep in mind companies don't think you are sexy after age 35...
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.
When you show up for a job interview, have examples of all the cool stuff you have worked on in your own time. Then it does make jack shit difference what degree you have or what the curriculum was.
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.
...You can program everything in brainfuck.
Of course, this would be silly and useless and imagine how risible it would be for someone to claim that not doing this (or not spending time learning how to do this) is somehow a detriment to one's ability to write working code for an actual application.
The fact is, we automate memory management for the same reason we write code to do calculations instead of pulling out a pencil and paper - it makes things /easier/. Is it sometimes necessary to bypass certain automation when the problem constraints demand it? Of course. Are these situations common enough for us to put forth some silly mandate that not practicing doing this makes you a lesser programmer? No, not in the vast majority of actual applications for computer science. Right now, in a vast portion of the computer science problem space, the programmer neither needs to know nor care about how memory is being handled. This was not the case a few decades ago. This is an obvious improvement, and anyone who says otherwise is a foolish idealist or an elitist twat.
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.
Firstly, "Yes", to your question. People who use managed programming languages (C#, Java, etc) are generally not as good programmers as people who use C, C++, Assembly, etc.
The reasons for this are multi-faceted, but can be broadly summarized as the difference between turning out fast, employable youths, and people who want to do specialized tasks. If you're looking to really learn how a machine works, skip the fast track to intro level developer / QA jobs and find something your passionate about--problems in vision, pattern analysis, whatever else. Then go do that and do it non-stop. If you are just looking for a starting developer role, stay with the Java track and learn more languages as you go.
Just my 2 cents. Enjoy. ;)
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.
If you learn one language to do everything, like Java, odds are that you are not in a Computer Science program, but are rather in a programming program. It's the difference between learning Electrical Engineering and learning to be an electrician.
Computer science is about how the things work, not how to program them. Computer scientists use languages as tools, rather than having the language as the end.
Has the school ever taught you memory management? File system structures? Anything other than Unix or Windows? If not, it's not a CS program.
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.
You can compare CS and Math to Physics and Chemistry. On the surface, Physics is more applied and deal with larger things (what happens if you drop an anvil on a freshman) where Chemistry deals with foundations: the atoms underlying the anvil and freshman. As physics grew, it got an applied branch (engineering) and a much more foundational theoretical branch (elementary particles, string theory and that sort of stuff).
On the surface, CS is applied math: big humming machines blasting thru multiplication as if it was addition. In reality, it has a practical part: dealing with programming and physical machines and a theoretical part. The theoretical branch of computer science (logic) is even more foundational than math. Foundational computer science does not concern itself with computers, but abstract computing devices (most know (of) Turing machines, but also GÃfdel's recursive functions, Chomsky's context-sensitive grammars and many other formalisms comprise the same). Here, we deal what can be computed (computing whether a program always terminates is not possible to do with a computer, optimally planning a route is) to the point of theoretical circle jerk (there are infinitely many levels of things we cannot compute, e.g.).
More practical is algorithmics, where we informally argue using Turing machine-like arguments, to classify complexity of things. Sorting using Bubble sort is slow, sorting using Quicksort is theoretically just as slow (bet you most didn't realize that), using merge or radix sort is faster (in the case of radix sort only in some cases). This level makes it possible to select the correct algorithm and data structure for a job (use an array if you need random access, use a linked list if you often add/remove elements). This level has circle jerk as well (is prime factorization fast? can we plan a route thru a number of cities fast?) Things like cryptography is a mix of math and complexity.
When it comes to distributed systems, things become closer to the real world, but still interesting; for example, the routing protocols uses a well-known gaph algorithm from complexity theory. Data-bases are kept in sync using various commit protocols. Assumptions are made, and we get closer to the hardware, while still dealing with purely abstract models (we can now pass messages in either a synchronous or asynchronous manner). No hardware is necessarily involved. Many distributed system concepts are integrated in modern enterprise application frameworks (e.g., queueing systems, redundancy algorithms for scalability and replication).
People who say you need to know C are not computer scientists. They are just old. Fuck C. C has its place and knowing memory layout can be useful in some cases. Most C programmers don't know enough about memory anyway and fuck up (knowing about cacheline sizes, caching behavior, etc. is more important than a smug working against the garbage collector). Anybody claiming C is better than Java because it gives you control of the memory is as dumb as somebody claiming assembler is better than C because it's faster (or writing machine code instead of assembler because you have control of the exact instructions which you don't have with modern assemblers). For 99% of cases, the computer is better at the optimization than you. This most likely goes doubly if you think you can out-smart the computer.
A good computer scientist needs to be aware of these levels. There's abstractions from the physics allowing semi-conductors, the gates allowing circuits, the processors allowing code to run, assembler, low-level languages like C, medium-level languages like Java, high-level languages like SQL, abstract algorithms like quicksort, math like Turing machines, and logic like why Aggerman's function is recursive but not primitive recursive.
Most people just work at a few of the levels. Know of the level above and below and ignore most of the others. If you make enterprise applications, know how a component container works and ignore deta
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.
Deva vu? http://en.wikipedia.org/wiki/Real_Programmers_Don't_Use_Pascal In fact, it's not about Java or C -- it's about how deep your knowledge, expertise, and experience go. If you think you're an expert because you googled up some code and copy-pasted it in your application, you're wrong. But you can only see this in hindsight.
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.
It's the same thing that is happening to airline pilots, they now spend most of their time just dialing in destinations into the knobs below the glare shield, so they "forget", over time, what it feels like to fly an airplane. So you end up with ridiculous situations where if some bees clog up the airspeed tube, the plane crashes, because the pilots have forgotten what a plane near stall feels like.
Garbage collection is just swell, really, really swell, until you actually need one large 2Gb chunk of memory for some reason and you find that you can't get it, because you have 347,677 little objects scattered all over the place.
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.
Nether, I'd get a construction crew.
"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.
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?
This co-worker of yours sounds like he's butt-hurt, because his memory management skills that he spent years honing aren't that relevant anymore. Unless you're looking for a very specific line of programming work, where manual memory management is required, your time is better spent learning other more valuable programming skills.
A good computer science curriculum should cover a wide breadth of subjects, and not just the current popular language and methodology. It should include, for example, one solid course of assembly language; algorithmics; operating system design; computational geometry; compiler writing; complexity theory; computer security; VLSI design; discrete math; user interface design. Students should be able to design a domain-specific language for a given problem and write a compiler for that language; reason about zero-knowledge proofs and use them to implement secure web transactions; understand the strengths and weaknesses of various languages and software engineering approaches, and suggest the ones most appropriate for a given situation.
(to those downvoting this: Hotel Charges Guests $500 For Bad Online Reviews)
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.
Computer Science is for theoretical things, like if you want to be a professor/teacher of CS. Learn to program by programming Arduino/Atmega/PIC or one of the many little processors, if you really want to understand what is going on. If you work at the enterprise level you will use Java/PHP or .NET most likely, and it's all an abstraction. But those things can almost be replaced by code generators. The coming 'thing' is IOT and for that you should know lower levels.I work wirh about 60 developers - a few of us know C/C++ and do that work when needed, but most are PHP/Javascript. It is good to know and understand assembly language. Useful with a difficult segfault problem or something like that, but we have not done anything in assembly in 20 years.Our strongest and best developers do in fact know C or C++, whatever language they use (we use PHP, Javascript, XHTML, XML, css, C, C++, Perl, Python, others). Developers who know Assembly/C/C++ also write more efficient PHP code (performance wise). Javascript/css developers mostly work on making pretty UI interfaces. PHP developers handle the enterprise/business aspect. The PHP is intermixed PHP/XHTML and Javascript/css, so all of our developers can do these.
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
Memory management is an important thing to understand, but to pretend like it is a daily concern of most developers is woefully misguided.
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
The College I went to I think only offered Java as an elective for the Software/Hardware Programming degrees. From start to finish, you get familiar with ~15-20 languages and/or variations of languages. All the CS majors (Software/Hardware/Electrical) start off with C and C ++ and then it diverges from there. I went the hardware route and I was still had to write programs in close to 10-15 languages albeit most were variations of other languages but still. I took C, C++, OOP, ABEL, ORCAD PLD, 8051 assembly, 8086 assembly, i960 assembly, verilog, vhdl, RISC, and others, I don't remember them all.
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.
If you master Knuth (algorithms), Kernighan (C and Unix), and Codd(SQL) you have a sold foundation to do anything in software. Learn from the masters, all else is noise.
To me, Java (and C#, et al) are C++ with training wheels. Until you get rid of them, you will never be able to properly ride a bike!
I wrote a deterministic reference-counted garbage collector for C++ - trust me, it wasn't simple or easy! That said, in 10 million lines of application code, there were no deletes, and no memory leaks. It was code that has to run 365x24 and downtime to clients had a cost of $10M per hour in lost profits... The fact that it runs most semiconductor, flat-panel display, and disc drive plants in the world today should say something.
At my last place of employment, we had a LOT of java code. The issues with memory management and garbage collection can cause serious system and performance issues. So much so, that we switched over to C++ and JavaScript. Even PHP has a reference-counted garbage collector.
That said, there are a lot of companies that are married to Java, and are looking for Java programmers. As far as I'm concerned, a little Java is ok. A lot of Java is a real PITA!
I didn't study at Berkeley, but one of my friends from work did. He pointed me to this lecture series, and I thought it applies very well here:
First read this list.
Then listen to this.
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
Seriously. Java abstracts you too far from the hardware. It's the attitude of "I'll not write efficient code .." (..because they can't and weren't taught to) ".. I'll just get a faster computer .." that's at fault.
Also to be fair modern CS wing-nuts didn't grow up in an era where you had a single student VAX with under 5 MIPS and 40 students logged in compiling, hacking, learning. You learn pretty quickly to be frugal with your cycles and CPU quota for the day.
It's all the spoon feeding and dumbing down that's the problem and enforcement of the ideas that "that's not necessary to learn.. and computers have advanced so it's not as important". This is partially true.
It's recently been amazing to watch some 2014 Java code vomited out by four top paid CS graduates in a 6-core Xeon system. It's a straight code translation with no feature creep yet. The goal is to replace a 20+ year old COBOL and C system on a sub 20 MIPS SMP system doing 71 of "our" transactions a second compared to the legacy system they're replacing that does 290 per second. Again, this is a straight code translation. They didn't even need to think. Also the legacy system stays up for years at a time, doesn't degrade to 5 transactions per minute once the 1024 mb memory heap size runs out and System.gc(); is being forcably called hundreds of times a second.
The great part was being lectured as to why this was a superior solution and how difficult it was to accomplish.
Not just these guys, but generally modern CS grads just don't get concurrency. They don't get compiler design. They're spoilt with too many MIPS. They don't get heap management. They have no attention span to sit down and 'really' think through an elegant, robust and efficient algorithm. They only know one language and don't have that rich diversity of concepts that came from being forced to do units in COBOL, C++, SmallTalk, LiSP, PROLOG, Fortran, Ada. These are languages that teach concepts and ways of thought, not "how to do everything with the same java screw-driver".
We're now investigating emulators which run our legacy system at close to 400 transactions per second.
no. they write glsl shaders
With regards to how much should one learn to be a good computer scientist.
Setting that bar is a personal choice, but you can pick from the menu of what's out there.
One would hope that at least a CS grad would have an inkling of the path available to him.
I'm not sure that is the case in most case.
Here's a strawman list:
A top to bottom understanding of what a computer is and how to it works from gates to objects.
Experience solving problems in an assortment of problem domains
Experience in what theory academic CS has to offer. (Art of computer programming updated to now?)
Experience is a variety of languages, systems, toolsets, etc.
Experience in programming programmers to build big systems.
A detailed knowledge of the guts (not just an operator or installer's knowledge) of a good percentage of the following:
data structures and algorithms
compilers and build systems
operating systems,
networking,
graphics,
web,
databases,
numerical analysis,
real time and embedded applications
data compression and encryption
digital signal processing
error correcting codes and associated mathmetics
no doubt many other things I've forgotten or not seen
A big bag of tricks with and understanding of the tradeoffs for six ways to solve the problem at hand.
Good judgement and temperament
Works and plays well with those pesky humans.
Good knowledge of what's out there to prevent reinventing the wheel.
Ability to teach and lead others.
A genuine curiosity to understand how things work.
A desire to make them better.
Not interested in World Peace, that's too limiting. Wants Universal Peace instead.
Looks good on beer commercials.
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...
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.
All these folks spending so much time learning how to manage memory never understand the big picture of an Object-Oriented application!
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 don't intend this to be sarcastic, so please don't take it as such:
You already have the answer...go write some C! (Or C++or some other language that makes you manage memory.) I'd recommend starting with a project that you already know how to do in Java, and re-write it in C (I found that school projects were great for this). You'll almost certainly have to start dealing with pointers, and stack vs. heap allocations once you progress beyond "hello, world", and the quickest way to get comfortable is to just write some code.
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.
Even in Java there are heaps of examples where to do something interesting with the host you have to manage the memory yourself because the native API methods you are calling are handing back to you system-allocated memory pointers.
Write a compiler.
I know it's mainly tongue in cheek but it's largely true. It's a generational thing. There are plenty of crapy CS grads of all ages. In fact most are not of much use (I am one by the way). That said I don't think it's been any different, at least not in the 25 years since I graduated. It's just that when you get old young people are stupid because you've ceased to adapt. This mixed with the fact that most people in general are stupid and useless gives the dinosaur plenty of "proof" to point at that say he's right and everything is going to hell with these young people.
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.
Computer Science majors are functional retards, period. And no, this is not just at a "shit school" that they always love to rebut with. And yes, I do know what advance CS courses are like.
CS majors don't learn a damn thing in university. They don't know how to code. The old adage that 99.5% of graduates can't code fizzbuzz level stuff in any programming language whatsoever couldn't be truer. Neither do they learn any really amount of theory at all. Sure they have courses in discrete math, algorithms, computability theory, but they are so watered down they can't really be said to cover much of anything at all besides merely definitions, yet they still manage to fail them in droves. Contrary to the name, they know nothing about computer operation despite having course in architecture nor do they learn any logical problem solving skills in either a concrete domain or the abstract. Apathy and ignorance are the king and queen of CS and constantly driving the curriculum down the drain as pressure mounts for more majors.
I would never hire a CS major for anything, not even mopping floors.
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.
It's not really so much about inferiority as much as the field of CS you want to spend your time and career focusing on.
But if you want to do operating system kernel development, you will have to know C/C++. Just take a look at Linux on Github.
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
Java is a good language for learning CS when used properly. Here is what I mean by that.
1) Design a simple assembly language
2) In Java implement a compiler that translates your assembly language into machine codes.
3) In Java implement a virtual microcomputer (CPU, RAM, non-volatile storage etc.) that understands machine codes that your compiler generates.
4) Learn to code in your assembly language
By the time you will finish coding a simple OS that car run on your Java-based microcomputer, you will be light years ahead of your peers who think that putting together a bubble sort algorithm or a simple web server in Java makes them skilled in computer science. That's how they taught me 20 years ago.
You could learn CS using only javascript and HTML5.
The reality is today's CS is really engineering and CS started out as a Math degree; somewhere in the middle of the transition was actual CS. Actual CS should be something that almost nobody learns. Software Engineering is the degree almost everybody is actually doing. As far as learning more hardware oriented things-- it's just not that big of a deal anymore and will be less so with time. For the few people who need to know that stuff, they can hire the CS grads (who'd have few job prospects) or the hardware oriented engineers. Oh, there is an obscure degree called Computer Engineering which is more hardware oriented; those people could deal with that.... I suppose CS people could work on compilers... Most demand should be software engineers-- and if they only know scripting-- fine, that is where it's most of it is going anyhow.
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
It really doesn't matter what languages are used for teaching provided you learn to see the wood for the trees and learn to find that on your own.
You can "learn" C or some esoteric machine code or Java and still be an awful developer, but you can also learn any of the above and pickup algorithms, data structures, design skills and independent personal development along the way.
"Is this a common concern with new CS grads?"
Yes ! : 'Oh. My program needs more memory, Just add some to the server.'
=> memory is nowadays cheaper than days of optimizing code. Yes this is sad and leads to awful situations as the software will hit new limits later and quite harder this next time. (and hey, let's talk about Environment Health)
"What can I do to supplement my Java-oriented studies?"
=> Find a student project which will push the machine to the limit. Response time should be part of the notation.
and Why not do a Coding Challenge ? a Code game with prizes for the most efficient solution ?
=> Students will find way to optimize code if it's a goal. if not, they would now be aware. Next they would listen to the good optimization advices.
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
My university does nothing but C++ in all courses. As useful as it may be to learn how to use it as a tool, it is very detrimental to understanding the concept. Take a course on compilers and language symantics where I have to write own parser, lexer, and abstract syntax tree manager handler. Or the Design Pattern class that is supposed to teach about Observers, Strategies. Doing it in C++ is a big problem. There is a massive overhead thinking about memory model and static typing taking away from focus on the concepts. I don't focus about how expression expands into another expression to complete a statement, how do tokens come together to form particular expression type - I think about how not to make memory leaks and annoying object allocation. By the end of the term I did not learn either. Understanding Design Patterns and algorithms same problem - I do not know how Strategy is supposed to solve problem of indirection and dynamic polymorphism. I barely know how to make the code to compile by deadline, much less understanding the patter. This also forces the lectures to go into a lot of details about underlying C++ architecture spending only a small percentage of the total time on what the course should be about. Huge part of the course was dedicated towards teaching how vtables work to be able to do Inheritence assignment, as opposed to the concept of Inheritence itself.
Java would have allowed me to focus and be good at the concept and learn memory management and other low level knowledge in courses dedicated to that, such as Operating System and Digital Logic.
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
The truth is that 4 years (and presumably only half of your classes during that time are actually CS-related) is not nearly enough to become a worthy computer scientist / software engineer / programmer. CS is a big field and expertise takes time.
Programming seems deceptively simple -- in the first few days, you learn all the programming constructs you'll ever use, and it's easy to think that as long as you have the kind of brain that can logically string together a chain of commands, you're already an "expert". But that's like assuming that because you know how to slap two bricks together, you're ready to go out and build the next skyscraper. It takes a lifetime to understand the ideas behind the many amazing algorithms and programs that have already been developed, and to develop the skills needed to make the next great software that will solve hard problems and change the world.
So yes, it's a shame that you don't know C/C++. But that's just the tip of the iceberg. You don't really know anything about programming yet. And it's not just you: Nearly all CS grads are weak, unless they've been studying CS since elementary school. Even those that have already learned C/C++ have a thousand other gaps in their knowledge, because as I said at the beginning, 4 years is not enough. Employers mostly have accepted this sad state of affairs, and are prepared to hire the weak graduates that universities produce.
My suggestion is to go out into the world with a sense of humility, accepting that there is so much more to learn. Know that you can not rest on what you've learned at university -- you'll need to spend the rest of your life learning in your spare time, reading CS books, watching talks, trying out new languages, studying algorithms -- if you want to be truly great.
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."
I hated it, but it does make you think about the bowels of the system. Maybe it is a good place to create a low level language that makes this learning easier. Of course my dad had to change switches and tubes on a huge board to program...then he got to look at machine code for fun.
Actually this also creates an issue with the user as well. The more user friendly we make systems and software the less the user will learn about what he is using. Don't get me wrong, I love usability, and I do not think a user should need to care what goes on behind curtain, but it also gives college students an inaccurate idea of what it takes to be a sysadmin, programmer, developer, analyst, etc. When that gets reinforced by teaching high level programming languages you receive a product that really does not understand how to see the entire picture of any data process.
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.
Believe it or not I had this discussion with a student a few days ago.
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!!!
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 few things to note as I have been working as a professional programmer for about 30 years and have taught CS classes for the past 19 years
Not all CS degrees are created equal
In general especially at the Masters level one would expect that you have learned
Automata
Algorithms
Compiler Theory
Some AI
Data Structures
Operating System
As such you would have had experience with a few languages and perhaps some specific languages you created for a class project.
So java would not be the only language you are introduced too and I actually think Python is being used more frequently in Academia than Java now.
Having said that MIS degrees and scores of other degrees out there don't cover everything I have mentioned. Of course day in and day out I tend to use Java heavily occasionally use C#,C++ and some C and javascript yada yada
So can you solve problems?
Are you willing to continually learn?
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.
I live in the database world, so I look a the data side of the house. If you cannot design data, you are dead and not amount coding will save you. The best you can do is to get the wrong answer faster. The author Jorge Luis Borges describes this example of an alternate taxonomy, taken from an ancient Chinese encyclopÃf¦dia entitled Celestial Emporium of Benevolent Knowledge.
The list divides all animals into one of 14 categories:
Those that belong to the emperor
Embalmed ones
Those that are trained
Suckling pigs
Mermaids (or Sirens)
Fabulous ones
Stray dogs
Those that are included in this classification
Those that tremble as if they were mad
Innumerable ones
Those drawn with a very fine camel hair brush
Et cetera
Those that have just broken the flower vase
Those that, at a distance, resemble flies
Or would rather use Dewey Decimal?
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