Slashdot Mirror
CMU Eliminates Object Oriented Programming For Freshman
fatherjoecode writes "According to this blog post from professor Robert Harper, the Carnegie Mellon University Computer Science department is removing the required study of O-O from the Freshman curriculum: 'Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum.' It goes on to say that 'a proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic.'"
I always thought the obsession with making everything OO when it doesn't suit every type of programming problem was a bad thing - glad to see some one agrees with me.
I don't know about *starting* in assembler, but a programmer who isn't somewhat proficient in assembler is going to have a very weird mental model of how programs work. OOP has the same problem--it's not that OOP is bad; it's that if you start out with an OOP language, you don't learn a lot of things that are important to understand. Once you know how the machine works, then you can start studying abstraction. Treating OOP as the only way, or even the best way, to solve any computing problem is going to tend to produce programmers who think everything is a nail. It doesn't mean that there are no nails, nor that students shouldn't learn to swing a hammer.
Why are computer scientists even learning programming? When did this happen? Programming sounds like one of those get-your-hands-dirty jobs in flyover territory, where you would show a lot of ass crack on the job and live in a trailer park. Educated people don't do that.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
I don't see why it should be removed, it should be 'complimented' instead with other programming methodologies in order to let users compare and contrast. But most CS in the end will end up being done with OOP so there's no reason not to start in the beginning - at least that's my personal experience.
In my first year we had a mixture of different programming types, including functional programming. I never really used any of those, I'm sure there are certain places where Prolog or Haskel is used, but its not as common as an OOP.
OO is practical for lots of problems, because it makes modelling real-world data easy. However, it is not useful if you want to give students a solid understanding of the theoretical computer science. OO is fundamentally data-centric, which gets in the way of algorithmic analysis.
To give a pure view of programming, it would make sense to teach pure functional and pure logic programming. If CMU really wanted to concentrate on the theory, they would have eliminated imperative programming from the introductory semesters, because it is very difficult to model mathematically. Apparently that was too big of a step.
Enjoy life! This is not a dress rehearsal.
Focusing on the basics, and not on the tools of the trade, is very important at something that is not a "trade school", and CMU's computer science department certainly lives above the trade school level. (Just to contrast: when I was a freshman, the "trade school" argument was whether new students should be taught Fortran or Pascal ! Thank heaven I didn't devote my career to being a programmer.)
It seems to me that CMU's made the very obvious decision that today, OO is a tool for craftsmen, not for freshman computer scientists. And they probably are right. It's important to not confuse the tools of the trade, with the basics of the science, and this is especially true at the freshman level. For a good while (going back decades) OO was enough on the leading edge that its very existence was an academic and research subject but that hardly seems necessary today.
In the electrical engineering realm, the analogy is deciding that they're gonna teach electronics to freshmen, and not teach them whatever the latest-and-greatest-VLSI-design-software tool is. And that's a fine decision too. I saw a lot of formerly good EE programs in the 80's and 90's become totally dominated and trashed by whatever the latest VLSI toolset was.
The big problem with OO courses has always been that there's far more focus on the mechanism (and, lately, on design patterns) than on actually structuring your program to take advantage of objects. The word "polymorphism" isn't as important as getting across the concept that you can coordinate a few things as if they were the same thing, and have them act in different ways. Knowing a bunch of design patterns by name isn't as important as figuring out once and for all that you can structure your program in such a way that you can create interfaces (not necessarily actual interfaces/protocols) between different parts of your program and essentially replace them, or at least rework them entirely without having the whole house of cards collapsing.
There's no focus on making it click. There's no course that teaches you explicitly just about formulating problems in code, and that makes me sad.
Agreed ... but aren't most modern OS's OO based? In most cases students need OO programming in order to become employable. OO certainly isn't the holly grail of computing but it is entrenched in business and needs to be taught just like COBOL was all those years ago (when I had to learn it even though it was like writing a book every time I wanted to write a small program).
Perhaps I'm misunderstanding the post... it sounds to me like OO techniques are only going to be taught in elective courses from now on. If that's the case, I think CMU is missing the fact that the majority of development work in the "real world" is done on already-existing platforms. Parallel/cloud computing and modular design may be the "next big thing", but what happens when the student gets their first job working with an application built with Java or .NET? Maybe in their ivory tower they can say "OO is dead" but in the real world, OO is very real.
I like my women how I like my sugar.. granulated.
Apparently the meaning of "Modular" has changed since I was in University back in '82. OO used to be the epitome of modularity.
But I do agree that making it an introductory first-level course does warp the mind of the young programmer. There are a lot of languages that don't enable OO programming at all (e.g. Erlang), which become much more difficult for them to grasp because OO is so engrained in their thinking.
I can't think of anything specific about OO that makes it poorly suited to parallel programming. There are languages whose nature is parallelism (again, Erlang), but that's usually accomplished by adding parallelism operators and messaging operators to a relatively "traditional" language. I don't see why you couldn't add and implement those constructs in a non-parallel language.
I also shudder to think how a CS student is going to deal with parallelism using languages that don't make it a natural extension if they're learning to rely on those extensions in their first year.
I gotta tell you, though, I really object to the use of Java as an introduction language for programming. Java is far from a shining example of any particular style of programming. It's not real OO because it's only single inheritance. It's not designed for parallelism. It doesn't have messaging built in. In short, Java is actually a pretty archaic and restricted language.
I do not fail; I succeed at finding out what does not work.
Given its toxicity to humans, I recommend avoiding drinking from the holly grail altogether.
Many kids coming to colleges these days do not have any programming experience or a very shaky one at best. Picking up concepts like classes, inheritance, the entire idea behind OO modelling is difficult if you are lacking basics such as how memory is managed, what is a pointer, how to make your program modular properly, etc. From the course description they are going to use a subset of C, I think that is a good starting basis for transitioning to something else (C/C++/C#/Java/... ) later on.
What is worse, many of these introductory courses were given in Java - producing students who were completely lost when the black box of the Java runtime and libraries was taken away - e.g. when having to transition to C/C++. We are talking engineering students here who could be expected to work on some embedded systems later on or perhaps do some high performance work. Even things like Java and C# still need C/C++ skills for interfacing the runtime with external environment.
I think it is a good move, indeed.
Comment removed based on user account deletion
I've found the same problem with SQL and prolog (of that was object prolog, scrub that)
thank God the internet isn't a human right.
The point of a university Computer Science course is not to train students in iPhone development.
Um. No. Many modern libraries or "frameworks" (newfangled word for library) are OO. Most OSes remain written in classic system programming languages like C and assembly language. In fact, most frameworks start as object oriented wrappers for certain OS calls and cruft up from there.
-- $G
Perhaps by not quitting after their freshman year, and learning some OOP?
"Convictions are more dangerous enemies of truth than lies."
Programming is about utilizing paradigms. Not being stuck in one. OO is just another layer on top of anything else. It is a set of rules that one can follow in any language. Some languages have it built in for convenience, but it is also an inconvenience for implementations where it is not so optimal.
There was definitely a moment when OO seemed to be some new paradigm in programming, but no, it is merely a tool, and CMU put it in its rightful place.
Geez, I don't know.
Most kids go to school for four years. Maybe they'll learn OOP in one of the other three?
Do daemons dream of electric sleep()?
Agreed ... but aren't most modern OS's OO based? In most cases students need OO programming in order to become employable. OO certainly isn't the holly grail of computing but it is entrenched in business and needs to be taught just like COBOL was all those years ago (when I had to learn it even though it was like writing a book every time I wanted to write a small program).
And how is this an argument for including in the introductory, freshman curriculum? I put forward the possibility that some topics may be more appropriate to be taught to students only after they've learned the basics.
"Convictions are more dangerous enemies of truth than lies."
Longtime Slashdot readers know and either love or hate user "Tablizer" .
He has a website detailing his objections to object-oriented programming, while arguing for "table-oriented programming". It has been a fruitful source of flamewars over the years.
So, is this a vindication for Tablizer? Tablizer, what say you?
I'm not a lawyer, but I play one on the Internet. Blog
If it means they stop doing everything in Java throughout their education, I'm all for it. There's nothing wrong with Java, and I use it often in my current company, but kids in school need to learn from the get go that languages are tools in a toolbox - use the right tool for the right job when you can. I can't remember the last time I interviewed a graduate who had used C++ or C outside of a single survey course on the language! Hell, I can't remember the last time I interviewed a post 2000 graduate who had built their own processor or had even taken an assembly class. The kids are just as smart, just as eager, but woefully unprepared. The one thing they are getting a little better at is included some 'software engineering' into the curriculum - but only a little bit better in that they do 'projects together' which in my experience means that the alpha nerd does 90% of the work and the other 4 team members offer worship and keep the ramen coming.
Loading...
Demeter, they tell me, was some manner of software project and the Law of Demeter is a style of OOP programming that is supposed to have come out of the experience on that project. In the strict sense, you are supposed to never invoke methods on objects embedded inside other object. Instead, the containing object is supposed to have a method that in turn invokes the method on the embedded object.
This manner of strict enforcement of encapsulation has the effect that most of your methods are mainly invocations of other methods. This may have the effect that any typical method invocation results in a long chain of method invocations.
This is kind of like I ask Phil for the monthly report and Phil tells me "you gotta get that from Sally." So I shoot Sally an e-mail and she gives me the monthly report? No, that is bad in some sense because if my contact is Phil I am not supposed to know about Sally. So I e-mail Phil with the request, who e-mails Sue, who e-mails Tom, who in turn e-mails Jason, who finally e-mails Sally. And when Sally generates the monthly report, she passes it back through that chain. So am I correct in thinking that OOP leads to such high levels of indirection, and programming styles such as Law of Demeter make this worse?
This style of programming probably helps coarse-grained parallelism of breaking programs up into elements that can run on separate threads or even processes. It helps by the rigorous enforcement of encapsulation. But this high level of indirection may break fine-grained parallelism -- every memory access chases long sequences of references.
Ironically, I find it vastly easier to encapsulate my mechanisms for parallelization in objects :).
Loading...
Major parts of the worlds telecom networks, for example the software in any of Ericssons equipment made in the last 15 years is written in Erlang. Nokia also uses a fair chunk of Erlang IIRC.
Software upgrades for some equipment used by the Swedish Defense Force, to accomodate the Network-Centric Warfare model used functional programming to.
I've used Erlang myself for semi-embedded networks that need to work in parallell.
I guess they want to build a nice moat to go with their ivory tower.
far better to hand wire logic gates and address decoders to have a real feel for what's going on.
Laugh all you want, but this was a big part of my intro to CS class way back before "CS" turned in to "using Visual Studio".
Programming is a useful skill and should be taught to CS students, that isn't in question. However, college isn't (or shouldn't be) a trade school. Programming is a bit of an art, and consequently shouldn't be a major part of any CS curriculum, certainly not the dominant part as it seems is the case at far too many institutions.
That said, first year students should learn to program, I'd recommend BASIC for learning basic concepts like iteration, flow control, etc. followed by an assembly language where they can get close to the machine while learning what's really going on as they implement common algorithms and data structures.
After that, it really doesn't matter what language they use in the rest of their core courses, as there shouldn't be a need to spend any time on even a new language in the rest of their core courses. Any class time spend on "how-to do blank in language x" is a huge waste.
On OOP specifically, I agree with CMU -- it's both anti-modular and anti-parallel. In short, it's a failed paradigm. Look at the hideous mess modern languages have become as a result of the nearly religious devotion to this astonishingly over-hyped and ill-defined concept! (Before the terminally incompetent chime in: objects are great, OOP is not.)
I applaud CMU for taking action here -- let's hope other colleges and universities follow.
Required reading for internet skeptics
OOP should absolutely not be taught at the freshman level, because it gets in the way of understanding more basic concepts like, oh I dunno, variables, branching, looping, subroutines, I/O, etc. Their claim that OOP is "anti-modular" is of course absurd. "Anti-parallel" is probably arguable, but how that's relevant at an undergraduate level of instruction is highly questionable.
At any rate the real problem is that colleges offer degrees in "computer science" but not "software engineering". How many of these students will finish their degrees without ever having committed to source control? Without coding to a 3rd-party API? Connecting to a database? Performing maintenance programming? Working in an honest-to-god team?
I actually have never believed that assembly is in any sense informative or educational because "it is how the computer works". It's actually a remarkably hard to decipher representation of a program, and what the program is and does is the important part.
I consider myself quite a strong programmer, and I never think in terms of assembly when writing programs. Higher-level languages, in particular functional programming languages, are far closer to my mental model of things. Why not work in a language that represents or helps formulate the problem-space abstractions better?
I want to play Free Market with a drowning Libertarian.
Ya I am not really sure I believe this article either, sure OO is not great for parallel but it seems a lot better then any alternative to OO I have ever heard of.
OO is great for parallel programming. The actor model of concurrency comes from object orientation! A number of OOP concepts come from Simula, which was designed for writing concurrent systems. It is a bit less good for implicit concurrency, but it's still pretty good if you have some profiling data to determine when it's sensible to insert the concurrency.
I read TFA when it was published a few days ago and it sounded like a theoretician trying to push the functional programming agenda by spreading FUD. There are some things that work really nicely in functional programming (e.g. software transactional memory via monads), but most highly scalable code uses a model where you have simple sub-programs that communicate via message passing, which (according to Alan Kay, who coined the term) is the definition of object oriented programming.
I am TheRaven on Soylent News
Ah, but in the same vein... CS classes aren't supposed to train them for the "real world" their first semesters. SERIOUSLY. Do keep in mind that CS is really a branch of theoretical mathematics (I should know...I studied CS and made the leap to Software Engineering...) and in order to grasp the actual study, you need more than just being trained for the "real world" (If you're wondering why I'm putting that in quotes, there's a substantive (dare I say a small majority...) of development work that just simply can't use Java or "pure" C++ and there's a nearly as large subset of programming that cause more problems than they're worth because it requires REAL skill doing the task in Java or "pure" C++ and many, many of the train wrecks are caused by someone using the wrong tool because they don't understand how the tool actually works- they were trained for the "real world" by their college in a CS or Software Engineering degree and they were ill prepared to make the right decisions.). Quite simply, you teach fundamentals first, then you branch off into functional and OO programming after the fact so they understand all the tradeoffs and actually can be theoretical mathemeticians or software engineers at their discretion.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
How about the Ericcson AXD301 ATM switching system, with over a million lines of Erlang?
Or...how about RabbitMQ?
Or...how about Facebook's Chat backend?
There's quite a bit more than you think and the three I referred to were using Erlang- there's loads more with some of the other functional languages.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I actually agree with that.
Or rather, it makes sense that students get a chance to sort of "climb up" to the current level of abstraction. Start out with basic electronics, digital gates, registers and ALUs, machine code/asm, C, OO...
Maybe I'm biased because I sort of followed that path on my own and I'm annoyed by all the developers out there who started out with VB using Visual Studio and then went on to VB.NET or Java using Visual Studio or some other IDE. I mean, I've worked with guys who think that something is wrong if they can't write entire GUI apps just by dragging and dropping with a few clicks in dropdowns. Sure, they may have a decent grasp of the larger systemic view and the concepts used in systems science but it just seems like they keep running into problems because anything more bare-bones than "click 'add data source', click 'auto-discover', pick your database and click 'ok'" is puzzling and black magic to them.
Greylisting is to SMTP as NAT is to IPv4
I sort-of agree with you; I am not making an argument that one "should not" know assemby, or at least the principles of it so you can read output even if you did not actually write it yourself. It's about being a well-rounded programmer.
My issues are more about this (mythical, to me) attitude that some people display that assembly is "the real thing" that is just hidden by abstraction in higher-level languages and that this is some kind of a mental crutch and that the assembly is what somehow actually "tells you what is going on". It leaves me with the impression that their thinking about programs and computation is not on a particularly abstract level, and I generally use "abstract" as a positive word here... think "abstract" in the sense of mathematics.
Of course, with a lot of modern programming languages, you don't even have a compiler that outputs anything, so understanding assembly is not going to give you any idea of what actually happens on the machine when you run, say, Ruby code.
I want to play Free Market with a drowning Libertarian.
Of course you don't want to teach algorithm development on a high level language that already has all of the algorithms (that these teachers are capable of teaching) built in. What would be the point of that? And I think when they said anti-parallel and anti-modular, they meant in the attitudes it instills in students.
--- start off topic rant ----
For the record, these degree programs provide you with skills tuned for different jobs. The CompSci folks are algorithm based - down in the details making things fast and efficient. The SoftEng folks are architecture/technology based - up at the top making things that WORK and that people can actually use; you know - products. They are COOPERATIVE jobs with a very large overlap.
Any CompSci should be grateful to have talented SoftEng helping them provide a cogent, fast, and polished view of their algorithmic efforts; your work means nothing if it never gets in the hands of the users or if it's spoiled by a bad implementation.
Any SoftEng should be pleased to have hard working CompSci making fast algorithms to help them to create their next product. You couldn't make these fancy architectures of you didn't have well thought out underpinnings backing you up.
I see some piss-poor attitudes on this thread and some of you snobs and dorks are in for a rude awakening.
I was crazy back when being crazy really meant something. (Charles Manson)
I outright laugh at people in an Interview when they ask me if I'll write OO code.
Good advice for those seeking work.
If you can't read straight up C code and understand what the fuck is going on, stop calling yourself a programmer.
They used to say that about assembly. Try writing a modern game or GUI in assembly. You might well be able to do it, but by the time your'e done I'll have finished several projects and be moving on to the next one.
If you can't code directly for the hardware you're interfacing with, stop calling yourself a programmer.
Right. Abstraction has no place in computer science education or in programming. As a matter of fact, if you're using anything other than a magnetized needle to right to your hard drive, quit calling yourself a computer user.
If you depend on .NET, any library, framework, or something written by someone else, you're not a programmer. You're a script kiddy.
Right. Code reuse is so lame. Anything that reducing development time and improves efficiency has no place in computer science. Everything should be written directly in binary on a computer you, the programmer, built from latches, switches, and flip-flops. Otherwise, you're just a bum.
OO should never be taught lest we end up with a generation of useless tools who think they're "programmers" that can't actually accomplish fuck all
Right. After all, every program written using OO is useless and nonfunctional. Except for the hundreds of thousands of programs that work just fine.
Go back to your garage with your unflinching dedication to The Old Ways and leave the rest of us to be productive.
An applicant for what though?
If I wanted a guy/gal as a back end systems and server engineer, I would want somebody with a well rounded CSCI education including assembler, kernel space programming, long running process experience, et cetera.
If I wanted someone who had to rapidly iterate client software because I was running a consulting firm, I'd prefer the person with the tech writing skills.
I've never seen a single job post 2000 that required students to know calculus either, but I'd still prefer to hire engineers who have had it.
Loading...
You're truly not giving Java enough credit. It is never good to learn from only one example but it can be used to teach compiler theory and assembly, as it is a bytecode VM, and DOES expose very low-level language details: you can freely use native types, even though they are awkward compared to objects. One of the best features is all of the threading and synchronization primitives you need at a low level are part of the language itself. So what if it doesn't compile to machine code?
Brian Fundakowski Feldman
So you can't call yourself an english major if you can't read Sumerian cuneiform?
While I also disagree with the tone of the parent, I hope you understand that abstraction and code reuse are not features that originate solely from OO programming? It is enough to have a module or package mechanism.
Yes it produces more powerful methodologies, because of the synergistic effects that objects have with modern cloud environments.
"Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
In a word, performance. In your particular field of expertise, performance and memory footprint may not matter (99% of desktop applications I suspect), but a strong programmer is fully aware of what goes on under the covers when [his|her] program is compiled to the degree that it impacts the product. Until recently, I never thought there was a functional difference between a lone line containing "i++;" "++i;". Of course, for variable assignment it matters, but what's going on under the covers? If you stop and think about it, i++ actually has to return the old value. ++i can destroy that old value and never needs to worry about returning the old value (you can avoid an extra copy). If you're in a high performance loop, either with not much body or with a lot of increments, such things matter. Understanding the impact of caching, the scarcity of registers, the high cost of flushing the cache, all of these can matter, and it's hard to teach these concepts without using at least a pseudocode that looks suspiciously like assembly. If you're paying for compute cycles, or if you're selling something in a market where performance matters, you're going to see a strong advantage in a computer scientist who understands assembly and compiling.
Now, if your main concern is code readability, maintenance and/or moving onto the next product as soon as this one compiles with no errors, higher level languages are undoubtedly far more appropriate.
but only a little bit better in that they do 'projects together' which in my experience means that the alpha nerd does 90% of the work and the other 4 team members offer worship and keep the ramen coming.
That's called "managing expectations", and is a wonderful introduction to their future careers for a lot of CS grads. Now go fetch me some coffee while this build finishes, would you? Thanks.
Dewey, what part of this looks like authorities should be involved?
It's a "library" if you call it from main(). It's a "framework" if main() calls you.
I hate frameworks.
I think you have a very limited view of what kind of programming folks do. Only a small percentage of folks do programming at the level where they need to know how a processor works. The vast majority of programmers out there work in high level languages like Java or SQL or XSLT where the nature of the processors capabilities, whether it is RISC or CISC or whether it is a multi-processor or uni-processor systerm doesn't matter a bit to what they are delivering. A lot of times you have assembler bigots on /. spouting things like "...you can write fast / efficient code if you don't understand how the processor works" or if you haven't programmed in assembler. I don't believe this. In the real world out there, what matters most in a huge percentage of projects speed of delivery of function points. If one has to compromise between a 30% efficiency improvement by using a lower level language, vs a 50% improvement delivery time by using a higher level programming language, then that 50% improvement will be the deciding factor in your company making a profit and therefore keeping you employed.
I have done programming in assembler. I have done programming C, C++, COBOL, VisualBasic, Lisp, and a whole bunch more languages for over 20 years. And my experience is that knowing how the processor works or a stack works, isn't helpful in 99% of cases..
I don't deny that in the embedded space, or to system programmers, that these details aren't important. But those programming spaces are a small portion of the programming market.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
You are still probably doing OO on some level even in C. OO is not a whole different paradigm, but is rather an institutionalization, so to speak, of a variety of patterns that are already used in procedural programming, with its own additional "enhancements" (for better or for worse).
I don't think the difference in job markets between C and Java really has a lot to do with OO as a methodology. It probably has more to do with what's available on what platform and what companies are using those platforms (more importantly, what *kind* of companies are using those platforms).
I agree, actually. Duke has run the gamut of teaching OO languages in their first year classes for decades now, from C++ through java to who knows what now. As a consequence, I end up teaching independent study students who want to actually learn C before they take the required course in operating systems. Most of e.g. C++ relative to C is bloat, in my opinion (although of course, sigh, stating this out loud in Modern Times simply invites the compiler flamewar to begin).
Personally, I think the best way to teach programming to future computer scientists is indeed to start with a course that mixes a foray (at least) into assembler followed by C. The best description of C that I've heard in numerous discussions on the subject (many of them heated, of course:-) is that C is a thin veneer of upper-level language sensibility on top of naked assembler (sometimes with the assembler literally shining through with inlined code). If your goal is to teach somebody computer science as opposed to train them for a job as a poorly educated web programmer, starting from the ground up in this way teaches them about the processor, memory, registers, basic operations, devices and interfaces, and much more as they learn to program, and in the end will make them far more effective programmers who write far more efficient code. Working without the "safety net" associated with higher level compilers also teaches them (sometimes painfully) to be careful.
Naturally, I expect nothing but flames from those who have focused one OO languages for their professional careers or who have drunk the kool-ade, but I cannot help but finish by posting a link to a bit of humor:
http://www.phy.duke.edu/~rgb/Beowulf/c++_interview.php
More than a bit of wisdom in this rather biting satire... I truly hope that Duke one day pays heed and returns to teaching its majors solid computer science starting at the very beginning and only later explores OO languages and concepts (and list oriented languages and concepts, and specialty languages and concepts and so on). And it is rather difficult to get more fundamental than C and still be considered a compiler.
rgb
Even when the experts all agree, they may well be mistaken. --- Bertrand Russell.
Programming is very easy, but requires math and logic skills.
I agree that learning the basics of programming is easy. But, like with any other trade, becoming a good programmer requires the right kind of motivation, curiosity, attention to detail, and desire to improve one's craft.
In my experience people who say "Programming is easy" are usually the ones you don't want to having working with you on a project.
Programming is a craft. You have to love doing it to be good at it.
Anyone can saw wood or swing a hammer. It takes a passionate person to properly build a staircase..
I just pooped your party.
I went to CMU. The curriculum is designed so that if you work hard, you can make it through the freshman courses without an incoming knowledge of programming; it's much, much easier if you know some basics coming in, but if you're motivated it's not necessary.
rage, rage against the dying of the light
A few weeks ago, there was a lot of discussion about how many universities are wanting to drop the math requirements from their CS degrees. Now we have dropping OO, too. I seem to recall that CS stands for Computer Science. Should not somebody with a Computer Science degree be able to handle things like OO and math? I could see dropping these requirements if the degree were something like Computer Technician or Computer programming (although even that last one, would indicate that a graduate would be verse in multiple programming paradigms).
Is all of this a continued dumbing down of college so that the masses can get a degree? If so, it appears more and more technical jobs will go offshore as the next generation of true computer scientists won't receive their training in this country.
On the other hand, if the goal is to pay a university a $100K to teach you how to do web pages and the like, then go for it. But, if the US wants to return to being a technology leader, then they need to focus on more than just the currently hot marketing skills and focus instead on the whole big picture.
By your logic, Universities should be teaching Cobol again. They STILL to this day 40 years after the language's hay day make massive amounts of money to basically maintain the ugly code of Cobol because nobody else wants to. Do you respect Cobol programming more than C? Then I suggest you detach the salary proposition from the equation.
I learned C in school and for years worked in companies where my job was in C. I was in a tight spot in 2001 when the bubble broke and I dove into a Java shop. I had done a Java course in school, but I would never consider myself competent in it at that point. The first thing I realized was "Damn, I can be so much more effective at coding in this language. I don't have to do any of the crap I had to deal with in the C world. It just works". I quickly fell in love with the language, and now years later I'm still a fan of the language even now that the sick plague of dynamically typed languages are flooding into popular use (again).
Bye!
its not compiler optimizations you're missing when you only learn java. Sure java does lots of stuff for you and does the "right thing" most of the time... But it doesn't teach you how things work at a low level. Learning only java doesn't teach you how indexes in a database work, because you just use Java's built in data structures that "just work" and you never have to learn how to manually build a b-tree. Which then teaches you how indexes work, and by deduction why its a bad idea to index every column in a database table. Yes, I once worked in a place full of java only programmers, they had indexed everything in the database to "make it faster" and were then completely confused as to why it wasn't faster. When I explained to them how b-trees (the database indexes were b-trees) worked, and how indexing in a database works in relation to that, they were actually pretty upset that in all the schooling they received no one ever explained this to them. They weren't "dumb" or "bad programmers", they just didn't know what they didn't know, once I explained it, they were very happy, willing to learn, and understand. For a couple of them it really opened their eyes and they'd come ask me questions regularly for the rest of the time I worked there... things like "I've always used java's built in sort functions, but why are they fast?".
Repeat above story for any sufficiently advanced data structure (linked lists, doubly linked lists, trees, queues, graphs, etc). Having a fundamental understanding of how the data structure works is imperative to being able to understand when its a good idea to use one, and when it will be an epically bad idea to use one. I learned these things in AP CS in high school which when I took it was c++. I "relearned" them again in c++ my freshman year of college, then the college changed to all java.... and I never heard mention of a data structure again, or for that matter an algorithm "Just use javas sort, its faster than anything you'll write"... Data structures and algorithms are still very important in web programming. Just cause you can get those 1.5 million rows out of a database doesn't mean you can effectively deal with that scale in code (much less 100 million or a billion records). I'm sure you can teach data structures and algorithms in java, my experience at a large state university though argues that java makes it too easy to gloss over the details... and so lots of professors will.
These single focusfunctional/imperative/O-O programming classes are teaching tools (techniques), not tool selection.
- that's where it all goes wrong. Teaching people in colleges about specific tools rather than about helping them to adequately approach a problem and to come up with a solution that is generic enough mathematically, so that it could be expressed in any language. The tools they will learn on the job.
Of-course if that's a technical school, then there is more merit in that sort of an approach, still I'd rather have somebody who can think his way out of a box than somebody who has a hammer.
You can't handle the truth.
You need not worry about that anymore nowadays, at least in C and C++. Recent compilers optimize the useless instructions out automatically.
My first program:
Hell Segmentation fault
If you come out with solid math and science skills you do fine. Programming is very easy, but requires math and logic skills.
That is certainly one (popular) route to take into programming. A strong background in linguistics also provides a solid mental foundation for programming. The important ability to cultivate is structured, organized thinking.
Man HS has gone downhill. In the 70's I had 6 years of math, 3 years of chemistry 1 semester of physics and 1 semester of programming in fortran. The card decks had to be sent to the main downtown facility to be run and they would send back thee printouts the next day. Now with computers all but free, your school could not come up with a VB course? Sad indeed.
Seriously, TeX is a great example of how being a great computer scientist doesn't make you a good programmer. From the concept ("instead of a typesetting program, I'll create a programming language which typesets as a side effect") to the implementation of that concept, TeX is evidence that they had some good weed in the South Bay in the 70s (BibTex, on the other hand, is a tragic illustration of the effects of the crack epidemic in the 1980s).
If you stop and think about it, i++ actually has to return the old value. ++i can destroy that old value and never needs to worry about returning the old value (you can avoid an extra copy). If you're in a high performance loop, either with not much body or with a lot of increments, such things matter.
Note that this only matters with overloaded ++ operators in C++. For the basic types, the compiler will optimize out an unused copy.
C++ and parallelization don't seem to be mutually exclusive. It's fairly easy to write a C++ wrapper around pthreads, so you have a class container for all the data, one or more functions to process a single thread task, and a single function call to scatter the data, assign and supervise so-many threads to the task and gather the data afterwards.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Sure, they may be "good" inside their specific niche, but they have no versatility in their problem solving.
Actually it sounds like you are the one coming from a specific niche -- probably some kind of embedded development. It is exactly the versatility in problem solving that is, in my view, not tied to any kind of processor architectures or anything of the sort -- it comes from exposure to both problems (in their abstract form, as the same stuff shows up in various real-life incarnations) and various kinds of solution styles. As my argument goes, assembly just simply doesn't provide the latter -- you still need to know what to actually do with it, even if you had to implement something strictly in terms of a processor architecture.
By the way, the most gifted programmers I have met -- really, "thinkers about programs" -- have been avid Lispers. Interacting with one years ago made me a Lisper, too... best investment in a programming language I ever made.
Just because something is modular does not explicitly make it good code, nor does it being non-modular make it explicitly bad code.
Modularity usually is a sign that the problem's components have been recognized correctly. In 99% of the cases a well written piece of code where the programmer has understood the problem, is decomposed sensibly into some kind of units. In the remaining 1% the programmer really better be a programming god, and even if he were, he still should have been able to do provide a better decomposition.
I want to play Free Market with a drowning Libertarian.
I think that CMU's point is that in a world where serial speed is stagnant, but where computers will become increasingly parallel (thousands of cores), a methodology that tightly links state and function, and which main mode of operation is to mutate state (i.e., OO) is not a likely candidate to stay dominant.
That certainly depends on what OO means to you. From what I can see, Linux is quite OO code - everything is quite modular and it's a very nice state machine. From where I sit, Linux itself can be considered OO code - just that it doesn't use classes or OO language doesn't mean anything.
non-OO code is like libc
Actually, not using classes does mean something: the code is more ugly, inflexible and hard to maintain than necessary. Speaking as someone who lives and breathes the stuff.
Linux kernel would be far better off actually compiling its class-oriented portions with a proper object oriented compiler. Likely as not, the code would be more efficient due to optimizations that can be done on virtual functions. Look at the hundreds of places where you have "if (obj->fn) opj->fn". In many cases that extra test is just pure overhead and can introduce pipeline stalls.
Still scratching my head about the linked article's claim that OOP is anti-modular. On the face of it, that claim is bold and counter to my experience.
Have you got your LWN subscription yet?
Yes, learning Basic at home helped me a lot with Java.
I had a little trouble at the beginning compiling with the line numbers, but I solved it quickly. Now my code is as efficient and good looking as everyone's else.
/* 10 */ public static in main(String args[]) { // This line does nothing. Brackets are empty and they did not even 'DIM' args
/* 20 */ System.out.println("Hello world!"); // semi-colon because the guys at Sun / Oracle didn't figure out that the line ends at CRLF
/* 30 */ } // Maybe this has something to do with the opening symbol at 10
Still working it with GOTOs, yet.
Why can't
Which is why a certain CS professor, you may have heard of him, he's called Knuth, uses Assembler in his somewhat reasonably well-known(some would call them the bible of CS) books.
I have a great deal of respect for Knuth and have implemented a number of algorithms from his texts. Particularly in the case of high precision arithmetic, it was necessary from time to time to actually read his horrible assembly language. The end result was good and tight, however I can say with confidence that his exclusive use of assembler for detailing algorithms is a blemish that weakens his monumental work. There are some cases where only a description of the algorithm in machine instructions will do, for example where a carry flag is an integral part of an algorithm, however the vast majority of his algorithms would have been better expressed in an algorithmic language.
That said, I will still continue to collect everything he publishes, and aspire to understanding more of his deep mathematical presentation.
Have you got your LWN subscription yet?
my experience is that knowing how the processor works or a stack works, isn't helpful in 99% of cases..
However, it is helpful in 100% of cases where efficiency matters.
Have you got your LWN subscription yet?
Isn't it great that we have optimizing compilers that'll take care of considerations like that for us?
A.. code should be written for clarity first, and if it turns out that it's not quite fast enough only then should you start worrying about whetehr or not it should be i++ or ++i.
As some readers may have guessed, "anti-modular," "anti-parallel," and "unsuitable for a modern CS curriculum" are one person's opinions, and do not represent the majority view of the CMU faculty. The introductory curriculum was changed away from Java for different reasons: primarily to focus on a language (Python) with simpler syntax and dynamic types, and to supplement with material on C that is closer to the machine. For more details, see a report by the SCS Deans:
http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf
Whatever you may think about delaying OO--and opinions are mixed at CMU as everywhere--one advantage of the new curriculum is that the sophomore-level course can do OO design more justice than we were ever able to do in the prior intro sequence, since the students already know how to program. Modularity and parallelism are in fact major emphases of that course, which I and other CMU faculty are currently developing.
Good god -- is there any human endeavor that doesn't turn people into raging douchebags?
Modern copyright is theft of culture from everyone and it retards the progress of the useful arts and sciences.