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.'"
So OO Programming because it's unsuitable for a modern CS curriculum. I guess we should go back to just assembly language so we can make sure we never go down this road of false progress again.
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 see the point of such drastic measure.
while I'm sure it looks strange to the jargon-speakers of the business world, it's nice to see some actual progress being made in programming education.
now, I'm not sure about the choice Standard ML over Haskell or Scheme, but at least we're seeing FP taught again at a freshman level outside of MIT and Britain.
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!
Well, maybe the correct way to say that is "modern CS curriculum is unsuitable for programming".
So "no OOP" == "some non-OOP"?
You must be a terrible programmer.
--
make install -not war
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.
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.
Is it just me or does this sound like someone has been listening to too much Talking Heads?
Is CMU an anagram for anything?
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.
...because all Fortune 500 companies have critical infrastructure written in some object-oriented language, most probably Java or .NET.
Now, I get "anti-parallel" what with manual synchronization, but Fork-Join (Java), Grand Central Dispatch (Objective-C) and whatever the C#/.NET equivalent is are supposed to go a long way towards solving these problems. Also, what's a real-world alternative used by large corporations? Clojure and Scala are by no means ready for enterprise use.
Oh yeah, and how is OOP "anti-modular"? What programming paradigms are "pro-modular"? C certainly isn't, nor are most functional languages.
This prof needs to get off his high horse and realize that his job is to prepare his students for the real world.
However I wonder on the reasoning: OOP is anti-modular? How that?
The Tao of math: The numbers you can count are not the real numbers.
give US a minute here. this can't be right? isn't there justdenyable homicide? that's the old time religion? god's will? too many of us (by about 5 billion)? still foggy? in these complex times, it can be disgustingly enlightening to return to the teachings of the georgia stone trustdead freemason 'math'?
Seriously? It's a little early for April Fools.
How will students learn the proper techniques to program for major OSes and platforms like Macs, iPhones (Objective-C), Android devices (Java), Microsoft's C#, Python, Perl, C++, and the dozens of OOP languages?
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.
Can someone name me some actual real world, large software projects based on functional programming? (Projects led by university professors don't count.) Dismissing OO completely because it is "anti-modular and anti-parallel by its very nature" seems kinda strange to me. I write parallel and modular OO software all the time... Maybe it's just me misunderstanding something.
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.
... as people claiming OO is the only way forward out of the mire of procedural programming.
Tools, jobs, you know the drill *sigh*
Thank goodness a university has finally decided to teach a curriculum based on what its professors like, instead of adhering to silly concerns about what might be useful in the real world. Students can rest assured that they'll get a first class CS education, and--sorry, what was that? Jobs? You want to get a job? What the fuck do you think this is, DeVry?
Now go finish your LISP homework!
The decision is sound, OOP mostly leads to bloated software, mind-bending and partly just plain stupid object-oriented constructions, and strongly encourages mutation. In a sense it's even based on the idea of mutating objects. Because of the dramatic increase in concurrent programming in the future strictly functional programming will be much more important than OOP. I understand that OO enthusiasts will not like to hear this, and of course OOP also has its good sides, but it is highly overrated. A good module system + immutable structures is much more important than classes and objects. If you use only immutable structures many operations with these structures can be parallelized massively without a single change to the code.
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.
This is a most welcomed initiative I would think.
First to address some comments, OO programming is not removed, but just shifted to the sophomore level. As a CS professor myself I get to appreciate the diversity of all students, and the different backgrounds they come from. In first year most of them have never programmed anything (of course there are also
occasional geeks, which can actually make the job interesting by asking more advanced questions) but for someone who had little experience in programming, starting
straight with OO is an abomination. First teach what a variable is, what a function is. What are side effects, recursion (very important). What are the basic data structures (stacks, queues, heaps, maps, and their implementation both persistant with trees, AVL and so on or mutable based on arrays, hash tables etc...).
Even more important talk about data-types, proper prototyping of functions, use a statically strongly typed language which enforces a strict typing discipline (and no you can't add strings and integers and no you can treat an integer as a boolean, not when you are just starting to program).
Then teach modular design, encapsulation, interfaces, modules, compilation unit. Teach the compilation process, linking process and basically how a program 'runs'.
Then ONLY you should teach about OO design (which is really not that bad and of course should be taught). OO relies on more complex concepts -- at least if you teach it properly -- (Classes, objects, methods, message passing, dynamic dispatch, overloading inheritance). It's just an heresy to teach what a 'method' is to students who barely know what a function is (both at the mathematical and programming language level).
And believe me once you know the basic concepts function, types, modules and so on, understanding OOP and actually using it efficiently when it's the best tool is much much easier.
No, you have terrible reading and logic skills, because what I summarized is exactly what the post to which I replied actually means.
--
make install -not war
we're not the only (chosen) ones? the natives must have made some mathematical errors? let's see, wasn't that problem taken care of before? & before that. let's check the georgia stone, all the answers are there? not to fret then, the #s never lie?
the GSM get their tiny (ie; selfish, stingy, eugenatic, fake math) .5
billion remaining population, & the money/weapons/vaccine/deception/fake
'weather' alchemist/genetically altered nazi mutant goon exchangers, get
us? yikes
the 'fog' is lifting? more chariots will be needed?
with real math, even being remotely involved in lifetaking (paying for, supplying endless ordinance) is also a crime against ALL of the world.
ALL (uninfactdead) MOMMYS......
the georgia stone remains uneditable? gad zooks. are there no chisels?
previous math discardead; 1+1 extrapolated (Score:mynutswon; no such thing as one too many here)
deepends on how you interpret it. georgia stone freemason 'math'; the .5 billion, then
variables & totals are objective oriented; oranges: 1+1= not enough,
somebody's gotta die. people; 1+1=2, until you get to
1+1=2 too many, or, unless, & this is what always happens, they breed
uncontrolled, naturally (like monkeys), then, 1+1=could easily result in
millions of non-approved, hoardsplitting spawn. see the dilemma? can
'math', or man'kind' stand even one more League of Smelly Infants being
born?
there are alternative equations being proffered. the deities (god, allah,
yahweh, buddha, & all their supporting castes) state in their manuals that
we needn't trouble ourselves with thinning the population, or being so
afraid as to need to hoard stuff/steal everything. chosen people? chosen
for what? to live instead of us? in the case of life, more is always
better. unassailable perfect math. see you at the play-dates, georgia
stone editing(s) etc... babys rule.
exploding babys; corepirate nazis to be caged (Score:mynutswon; hanging is too good for them?)
there are plans to put them, (the genetically, surgically & chemically
altered coreprate nazi mutant fear/death mongerers (aka47; eugenatics,
weapons peddlers, kings/minions, adrians, freemasons etc...)) on display
in glass cages, around the world, so that we can remember not to forget...
again, what can happen, based on greed/fear/ego stoking deception.
viewing/feeding will be rationed based on how many more of the creators'
innocents are damaged, or have to be brought home (& they DO have another
one) prematurely.
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
No, you have terrible reading and logic skills, because what I summarized is exactly what the post to which I replied actually means.
Hmm. Nope, not even close. Looks like the pot calling the kettle black here... except the kettle isn't black in this case, just the pot. In any case, your logic and reading comprehension skills are sorely lacking...
"Convictions are more dangerous enemies of truth than lies."
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.
I do not know if OOP is anti-modular per se, but almost every implementation I have seen had serious problems from a modularity point of view.
Worst is of course C++ where OOP means you no longer have any encapsulation at compile time, but you need to almost recompile everything most of the time some private fields change.
But even with more complex module systems not relying on header files, OOP means your interfaces are likely to contain object hierachies even where the object hierachy is realistically mostly a implementation detail (or at least should be). Thus you either need interfaces changing more often or the code no longer having a suiteable interface, which usually is visible by having glue code on at least one, often even both sides of the module's interface.
When you write proper OOP, you have a whole building set up, with methods, classes, and stuff. That's not a three-liner, and that's not easy to modularize and reuse.
It's about the same as with anti-parallel. It was (and is) a nice paradigm on a high level or a high layer. You inherit stuff, you call methods. You try to be complete. If you cut down problems into single simple pieces of Lego, you don't need all of that. You write a small utility that does a complete mediation on the date entered. It doesn't need OO.
On a very high level, or a user interface, it is much more intuitive: You create a file, and you can duplicate it, manipulate it, print it. Left mouse button - right mouse button.
The style of mutating objects comes about when you don't have good garbage collection. You want to avoid creating immutable objects that you have to discard as this stresses the garbage collector.
But they tell me there has been considerable progress in garbage collection, both in theory as to how it could be done and in practice in later versions of Java. The Java people are now encouraging the use of immutable objects because they claim their garbage collector is efficient enough to handle this style of programming, even thrives on creating objects with short lifetimes.
I guess they want to build a nice moat to go with their ivory tower.
No. The article says CMU is eliminating OOP training, saying it's bad. You agree, saying "it doesn't suit every type of programming problem". You therefore are saying that since OOP isn't good for everything, there should be no OOP. Ignoring the alternative of teaching some OOP, but not exclusively OOP. In other words, "No OOP" == "Not some OOP".
Yours is the fallacy of the excluded middle. Look it up. And don't ask me for any programming jobs. Or any that require logic. Or recognizing your own limitations, even when they're shoved in your face. Because then you engage in the denial projection that makes fallacists like you so annoying.
Goodbye.
--
make install -not war
It's just Doc Ruby being himself. It gets even worse; he's also a Space Nutter. Not only can't he read, he also believes there are fantasy-levels of energy and technology out there. He actually thinks we'll make aerogel in space to insulate windows...
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?
So you say it's only "proper" OOP if you build a complete framework? Well, then maybe my idea of OOP isn't exactly proper ... maybe I've gotten too little OOP evangelization :-)
The Tao of math: The numbers you can count are not the real numbers.
My CS101 class (many moons ago) was taught in Scheme. I thought it was fantastic. Since I didn't come from a high achieving high school, I had no formal software training beyond what I hacked on my home C64 w/ Comal. I was nervous that I was going to have to compete with a bunch of C/C++/Pascal trained gurus. Scheme was the great leveler. Nobody had a clue with the language, and the professor could focus on CS, and the programmers had no advantage in the class (i.e. couldn't coast).
Bring back CS101 as Lisp/Scheme/Logo (not the turtle part, the actual language). Make their brains hurt.
"Uh... yeah, Brain, but where are we going to find rubber pants our size?" --Pinky
As long as a program doesn't crash or dump core (re: Standard ML), its output must be correct.
Well, C++ isn't really an argument because here the main problem is the archaic header file model, which just doesn't fit modern programming methods.
And the hierarchy problem you mention is in part due to bad design (needlessly deep object hierarchies), in part due to an insufficient adaption of OOP to static typing (dynamically typed languages don't have that problem; AFAIK OOP was originally implemented with dynamical typing), esp. that you are forced to declare all supported interfaces at class declaration time (and yes, I don't know a statically typed language that doesn't have that problem; nevertheless it's not a fundamantal problem of OOP, as dynamically typed languages show, and IMHO even solvable for statically typed languages), and in part the classic interface mismatch problem which is completely independent from OOP (if you have to use two interfaces together which don't really match, you have to write an adapter; it doesn't matter if the mismatch is in object interfaces, in library APIs, or whereever; for example, if a sorting library expects a less-than function, but the library providing what you want to sort provides a three-way compare, then you must adapt the interfaces by writing the less-than function the sorting library needs using the three-way compare the data type library provides, no objects involved here).
The Tao of math: The numbers you can count are not the real numbers.
The Java/C++ model of O-O pretty much forces side effects and object mutation on you.
Other models of O-O exist. CMU is using "O-O" as shorthand for "pedestrian, non-academic coding".
Which has some degree of truth, but is also academic snobbery.
If they wanted to advance the conversation without flamebait, they could have labeled their stuff as "modern O-O" or "O-O without mutation" so they could not look like they were throwing out the useful aspects of O-O.
To a Lisp hacker, XML is S-expressions in drag.
Object-oriented programming is eliminated entirely from the introductory curriculum (...) 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.'"
Dilbert RSS feed
in developing office style applications, not high performance ones.
Also it doesn't have its place, indeed, when starting to learn programming; kids need to learn to think "close the metal" to understand why things go wrong, otherwise they will be forever relying on the documentation of some blackbox OO API and understand almost nothing.
When they grow up and understand the "zen of programming/computer science" then yes by all means use OO/Java/C#/C++ whatever to save you time and not reinvent the wheel.
After all you don't learn to drive before you basically understand how an engine works do you? right? ... sigh...
Go, Objective C.
The prof cites Meseguer's Solving the inheritance anomaly in concurrent object-oriented programming as an example of the problems of trying to mix OO with other concerns, in this case concurrency.
If the tool doesn't work, pick a better one!
--dave (who uses O-O happily for non-parallel tasks) c-b
davecb@spamcop.net
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)
What the hell? How does that follow?
OO is fine in theory but, oh dear, what a mess in reality. I would love to know how much OO has negatively impacted software development over the year. Find a disastrous project and I'm sure there will be a whole load of OO there boggling the mind. The problem is that the object design at the start of the project typically has no bearing on the model after some years, and the cost of redesign and refactoring over and over is terrible. And don't get me going on design-patterns! Lets take OO and move it beyond the whit of man, or at least 90% of developers.
OO is fine for small-scale objects, like UI widgets. Or very large container objects. But in between, oh my god.
Now I know this will be flame bait for a lot of slashdotters, but only because you have been brainwashed into thinking OO is good. Like how physicians thought blood letting was essential to balance the humours 200 years ago, but now viewed as a relic from the dark ages.
No, the answer is not assembly code either (even though I still have my 6502 hex codes by heart).
First language I learned was LISP. Second was assembler for an old Univac machine. Then SPS and Autocoder for the IBM 1401. Then BAL for the 360 and finally FORTRAN. After college and the military I got into C (in 1972). C and LISP served me well until I got onto a project using SMALLTALK. SMALLTALK was really fun, but I think it was the nice IDE rather than the language that made it fun. By the mid 90's OO was all the rage and as the education factories started turning out Visual C++ experts it looked liked C++ would be the language forever except those Visual C experts could not create a class library to save their lives. They basically used it as a procedural language but there was great confusion as many people believed if it was written in C++ it was OO by definition. OO was what the cloud is today. A clearly defined environment, with all of 12 people really getting it, and thousands thinking they do.
My thinking is that LISP was a great language to start off with for many reasons. These days I really like Python for general stuff, and I have not been close to a programming project in years so have no idea what is best, but would look at the tools first.
By the way, assembler and machine language doesn't help. The theory is that if you understand the machine internals and architecture your code will perform better. Not true. Understanding the machine does not prevent you from designing a web app that requires 50 DNS lookups, 150 database calls, and 150K of javascript for the first page. If you like to drive a stick, you should learn assembler, you will like it. If you want a car with all sorts of gadgets and fly by wire, you do will find assembler very boring.
So I think CMU is on the right track. But there is one last thing I have noticed over my many years in the industry. Whichever language you learn first will likely be the one you favor forever.
This is more about having a curriculum that stands out in the crowd than solving a real-world problem. Now that Hyderbad Tech, ITT, and University of Phoenix are all teaching Java they need to show they are somehow above the noise.This is the marketing department influencing curriculum.
When hiring programmers, I have long believed that the best programmers completed their college degree because they need that to be considered for employment by most corporations. These excellent programmers come to college already knowing nearly everything they need to know about programming, what they get in school is mostly theory. They are just going to school to check off a box on their resume.
In fact, in considering a candidate for a programming job, I consider a master's degree in CS a strike against the candidate, and a PhD TWO strikes against the candidate. CS students who are good at real world programming usually can't wait to finish their degree so they can get out there and get a real job; students who are good at theory are the ones who get the advanced degrees.
Objective-C doesn't count -- it does not solve the problem for static types, it just falls back on dynamic typing. A better example is OCaml, which actually does solve the problem while remaining completely statically typed.
and let god sort 'em out
I don't know the meaning of the word 'don't' - J
I actually being my one-on-one programming crunches with reality and what problem was solved, then evolve to analog electronics, then digital electronics, then explain the reuse of digital components by creating an engine (microprocessor). I explain the branching to FPGAs from here. Then I move to assembly, then C, since C is basically assembly using a pattern for calling and variables. Then show how objects can be represented in C and pointers to methods can do method abstraction and OOP can be done in C, then C++ showing how much easier it is for OOP and name-spacing. This is where i am currently. next going to progress into C#
I always thought OO was unnecessary most of the time and everyone was just forced to do it because "it's what you're supposed to do" even if it makes it more complicated. I thought we were supposed to keep complexity to a minimum?
Both Microsift and OO on the decline in the 2010s? This decade is gonna be awesome!
Whoosh!
There are people who argue that CS isn't about programs, that CS is as much about programs as astronomy is about telescopes. Those people will tell you that practical application of CS is an entirely different subject.
Those people are wrong.
There's a reason that in the 30s before we had computers that CS was studied by about 20 people; there was no point. Ditto number theory. Nowadays we ahve computers and public key cryptography and both subjects are important now, with many many students. We study CS to make better programs, to make better computers, to use computers more effectively. You can fairly make the comparison that a computer programmer is to a computer scientist as a car mechanic is to an automotive engineer, but I got news for you; the first mechanics were engineers. Like Bruce Lee said, "knowing is not enough. We must also apply."
If you don't believe CS should prepare you for a career with computer or that college isn't there to prepare you to be an effective worker, you need a serious shift in perspective or people will very quickly stop caring about your opinion.
It should never have been first year stuff. It never was in my university as far as I remember. Anti-modular and anti-parallel? everything is. You got the wrong reasons, which is not surprising taking into account you already screwed up before by teaching OOP to freshmen...
I was wondering when this was going to happen. The future of hardware is obviously towards parallel processors, in which the burden of further exploiting code parallelism is placed explicitly on the programmer, and not on the hardware or compiler. It makes sense that up and coming programmers should be seeded with this mindset above all others, and this is exactly what CMU is doing. Other universities should take note, and we should applaud CMU for taking that first step towards the new world.
This thread is comedy gold, especially the part where instead of re-reading the article to see if he missed something (given the accusations about his reading comprehension), Doc Ruby pompously accuses others of being in denial. LOL.
And don't ask me for any programming jobs. Or any that require logic.
Don't worry, Doc. After your display here, I doubt anyone would want a job from you. Most people prefer their bosses to be able to read and understand simple articles, admit when they misread something, and not try defend their misinformation by accusing other people of "denial".
Or recognizing your own limitations, even when they're shoved in your face. Because then you engage in the denial projection that makes fallacists like you so annoying.
Comedy. Gold.
I got this idea, I know it's crazy, but don't dismiss it right out.
How about they start teaching people "thought oriented programming"? You know, thinking about the problem first, coming up with solutions to questions, ideas, figuring out the best tools for the jobs and then using that to do the work?
any traction?
You can't handle the truth.
Actually Python is functional and imperative as well...
OO is in my opionion the uglier part of Python ( __blah__)
OTOH look at this:
primes = ( i for i in range(2,100) if not any( not i%j for j in range(2,i) ) )
It of course depends on the kind of OOP you use. Things like Haskell's classes (which from other point of view are not really classes, but rather interfaces) is a thing that can make module interfaces better. But many "OO languages" do without interfaces at all and only have inheritance.
Even without modules there is a problem there: Consider for example an ordered list. An ordered list stored objects, which it needs to compare.
So without interfaces you need some base class with a comparison function. With inheritance you cannot express that this comparision function only compares with other objects of the same type you use as base of everything in your list, but you must be able to compare it to everything else which is a specialisation of the comparison class (which is of course impossible, so you will have functions that check types at runtime and throw runtime-exceptions even though compiling totally fine).
Now things get worse without polymorphism (which a majority of "OO languages" also miss). Then you cannot have an class just for comparing, as your real world objects would already need to be inherited from some other class to be usefull, or you already have your first layer of glue code. So you need some base base class that already has a possible comparison (many things will not be able to compare, but as you must formaly be able to compare with anything else comparable with anything, 'not comparable with this' must already be a possible outcome, so everything being comparable needs to be a 'valid' result anway). So you have a base base object class with all those things anything might later get. And if you need anything additionally, you need another base class.
Now in this case consider an reuseable module. If you have no interfaces and no polymorphism, it needs to have the same base base class you use, or you cannot use it without extra glue. With polymorphism you need an extra class in your inheritance for every other module you
want to use.
So if you have some object that some module exports, that module needs to have ancestors depending on the what other module you internally use. So you might need to make the other module, though only being an internal implementation detail, be part of your interface as you cannot describe your object without it. (If you need to describe all the interfaces something supports here, interfaces do not help either).
That is the main reason in practice OOP is anti-modular: implementation details are leaked, as they get global properties. For every such problem there might be a language that has some form of OOP that does not have that problem (I love Haskell's object orientation for example), but in mainstream languages OOP just means: sorry, no modularisation for you.
He actually thinks we'll make aerogel in space to insulate windows...
One wonders why you would think that is hard, much less part of the "fantasy-levels" of technology. I guess having a remarkably stilted understanding of technology is a prerequisite for your belief system.
I must be an idiot.
How is thing_do_stuff(the_thing, params) better than the_thing.do_stuff(params)? Why can't I call do_stuff on my things[] in a parallel manner?
I guess this is why I need to get my ass back to college to study for a career that doesn't involve hand-waving mumbo jumbo clouds and widget_factory_factory_factories. I just can't take the buzzword bullshit anymore.
Join the Slashcott! Stay away entirely Feb 10 thru Feb 17! Close all tabs to prevent autorefresh!
Freshman classes should be taught in C with strict typing (i.e. no type casting). This way, people understand about direct memory model, and work on algorithms, like searching, sorting, parsing, traversing networks, etc. The language should be absolutely minimal. Programmers need to understand what a pointer is. Interfaces, inheritance, and polymorphism are things people should learn after they know how to write a program that actually accomplishes something. I interview interns all the time, and I ask them what they're doing:
Idiot: "we're learning about object oriented programming"
Competent: "I wrote a program which generates a triangulated irregular mesh from an elevation grid"
I'm guessing this comment / question will not see the light of day due to my lousy rating, but here goes nothing:
I'm an electrical engineer making a decent living practicing applied electro-magnetics and communication theory. As part of my program at a slightly above average state university in the late '90s, I was required to take a semester of C++. I also took a second semester as an elective, but mostly coasted through as it was my final semester and had crammed in 13 other credits in required courses to finish.
Now, I certainly don't make a living writing software for public sale, but I do occasionally want / need to automate hardware and software tasks. My software development "language" choice was generally dictated by what was at hand, or with what I wanted to interface, or what had already been done. I've used TCL, LabVIEW, VB, Scheme, LUA, among others. I'm not an expert in any of them and I certainly am not an efficient programmer. I haven't had the need to use C++, or any similar language, but I do feel as though the C++ course that I was "forced" to take was beneficial. Specifically, I learned about programming syntax, how to read and debug code, and what arguments and built-in functions you should expect from any other language. More generally, I think I learned how to learn a new language which has been indispensable.
Is C++ the best language for learning what I did? It seems to have done okay for me, but I probably learned and forgot a lot of OO stuff that isn't very useful for what I do (quickly bang out some software to automate the task at hand) and maybe C would have been more applicable. Thoughts?
Not sure where that notion comes from, and I've been programming professionally for 30 years...
One of the earliest languages to encourage modular programming was Modula-2 (a successor to Pascal, popular in the early 80's), which defined a module as a collection of types, data and functions with a public definition similar to a C/C++ include file (bt withing a namespace), and a private implemention. Most C (not C++) programmers arrive at a similar style with a related collection (aka module) of types, functions etc defined by a header file with the corresponding implementation in a seperate .c file.
C++'s classes (or C#, or Java - all very similar) at the most basic level formalize this type of modular programming by collecting related types, functions etc together and separating the public interface (definition) from the private implementation. This is what modularization is all about - divide and conquor complexity by grouping of related functions together and seperating interface from the more complex implementation.
Of course O-O languages and design go beyond mere modularization, but still that's at their core, and to say that O-O design is anti-modular is ridiculous.
The objection of O-O programming being "anti-parallel" may have a sligght graiin of truth to it to the extent that parallel programming is still a very fluid field and imposing any other methodology does impose some structure that might not be helpful. However, modularization and O-O classes are not inherently anti-parallel by any means... classes that encapsulate and hide the implementation of parallelism from the user are a very powerful technique.
As someone at CMU in CS, I can definitively say this doesn't mean we will never teach Java or C++. Lots of courses will still use these languages and OO-concepts. We are simply changing the focus of the introductory sequence of classes (100 and 200 level), which students complete by the end of their sophomore year.
Then you are a fool to go to go to CMU. Because they clearly don't know what they are talking about. All modular and parallel programming is implemented in an OO manner. If you don't have OO skills good luck finding a job. Is this a joke? April Fools is next week...
That was what I was wondering. Properly designed OOP should result in modular code that can readily be taken into a new program or modified. Sure, you don't have to program your Java using the objects and OO aspects of the language, but you could also write in C without the use of libraries or various defines as well, doesn't mean that it's fair to say that it's anti-modular though.
"not easy to modularize and reuse?" What exactly do you mean by this? So far in my studies, I've been learning about making my classes as generic as possible just for the explicit possibility of finding use for it in another project, later on. 0_o
If you believe in privacy, and believe you have "nothing to hide" at the same time, you're a goddammed idiot
A case made on when NOT to use objects and how to deal with a high degree of parallelism: http://www.cs.colorado.edu/~ralex/papers/PDF/OOPSLA06antiobjects.pdf
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.
Ha ha ha, CMU frosh! You will now see academic wannabe-mathematician types in your first year! Wee! I had Scheme and CLU and Multics. Guess what: every Ivory Tower CS prof is going to inflict their bias and history on you. You will have to learn useful skills outside. Only occasionally will you recall utility from the classes, and the utility will have been developed by 'commercial' languages because they actually need it, its not just more Wordsmithing. Remember: Academics get paid for wordsmithing and grant-grabbing, sometimes teaching; not building things. Study and contemplate, but keep it in perspective. Just look at the abstract crap in the CMU screed.
Object types aren't particularly antimodular. They're not particularly promodular either, any more than functions are.
That's one of the things I like about Modula 3. It has modules. It has object types. And they have nothing to do with each other.
What gets to be antimodular about object types is the idea that they are the only kind of module. Some languages enforce this, meaning that everything that has different natural modular structure has to be perverted to fit into the object type formalism.
-- hendrik
Try to use some more complicated template, make some unconscious mistake, and then try to find out at runtime WTF the error message means!!!!!
That's why Carnegie Mellon's computer science program has such a poor reputation in the field.
My view is that OOP is a better response to Structured Analysis and Design (you
remember Yordon/DeMarco?) than it is to general programming. You know those big projects where some Manager who does not understand that english is not a very good language for explaining what the EXACT requirements are. He does not understand programming at all. He is very insecure about what those "programmer geeks" are doing. Demands a big and mostly incomprehensible SRS (System Requirements Specification) because that is what a Structured programming project
needs. Can be convinced that a UML document does indeed reflect what he has
said he wants and the programmers can be convinced that they understand what
the UML diagrams mean.
Ignoring the problem that the manager seldom understands what it is he needs,
this helps, but does not resolve, some of the issues around the interface between
the customer and the developers.
It does not come close to resolving all of the problems with a software project.
When I was an undergrad (when dinosaur ranching was still on the aggie curriculum) there was a fledgling computer science program in Liberal Arts and a strong program in Engineering. I still think there is a distinction between Computer Science and Software Engineering, similar to a distinction between Physics and Electrical Engineering. Both cover a lot of similar ground, but in a different manner and with very different focus. They also produce very different products (graduates). In a real Computer Science undergraduate curriculum, OOP should be covered as one paradigm for implementing theoretical thingies like command and data structures. One of MANY such ways. In a Software Engineering curriculum, OOP would be one of the tools learned in order to craft software.
So, I don't get all a-flutter with this particular FA. In fact, it makes a lot of sense in the context of science (theory) vs engineering (practice). Yes, a CS graduate may not be able to code up something in the latest language-du-jour, but I'd hire one of them if I was wanting to build a new OS or a new command/control language. If I want someone who can get down and dirty to build a serious software widget or system, I'd hire an engineer.
That's just your opinion. In my opinion OO does suit ever type of programming problem. If you read a bit further they say that the object oriented programming module is replaced by a object oriented design model, so the wheels are not coming off
The widespread use of "Design Patterns" is useful in explaining why OO should NOT be taught to college freshmen.
I view design patterns as an alternative methodology to OO methodology. Design patterns allow the productive use of OO languages without the unproductive baggage of OO methodology.
OO languages were originally created to facilitate the pre-existing ideas of OO programming and OO design.
Then, when programmers actually had these languages, they evolved a way of using them that is radically different than what was originally intended.
Clearly, there is enough value in OO that the languages are worth using, and enough difficulties that the methodologies are not worth using.
I expect that the next generation of tools and methodologies will take what is good from OO, and forget the rest.
In the mean time, I don't see the value of explaining to college freshmen a set of tools that were meant to be used one way, but in practice should be used a different way. (Actually, I do think that is a valuable lesson. But I think most freshman level courses treat the techniques being taught as unambiguously good.)
http://xkcd.com/756//
In other words, an SML signature is what OOP calls an interface? (Okay, sure, Java forces all objects to support stringification and comparison for equality, but that's not really a fault in OOP.)
Of course, one has to recognize that extends is evil:
Someone asked [James Gosling]: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.
These people have been drinking too much magic cool aid. Verification of software has never and will always be an obscure, special-purpose technique; it will never go mainstream, not just because it doesn't actually work, but because few people are capable of doing it. And ML-style functional programming has been around for ages and has never amounted to much either.
And to say that "object-oriented programming is anti-modular and anti-parallel by its very nature" is idiotic; whether it is modular and parallel depends on the abstractions you implement in it. Of course, you can't automatically parallelize arbitrary messy object-oriented code. But, you know what? You can't even parallelize arbitrary functional code well in the real world (even though theoretically it looks like you ought to be able to).
If people want to teach functional programming as part of an introductory class, they should go back to the tried-and-true: Scheme and SIPC.
Awful close to April 1st
Does PIC device programming fit the OO paradime NO and neither does 90% of technical programming or at the high end does IBM Mainframe assembler work with OO NO.
When I interview fresh grads, the ones from CMU consistently score better. I have even commented on this to coworkers quite a while ago. It's not an isolated incident, literally dozens of candidates impressed me with their grasp on embedded, kernel and system programming. Usually I'm disappointed by the people I interview.
“Common sense is not so common.” — Voltaire
I am a bad programmer because i don't blindly apply one model to every problem ?
Alice.org is an OO graphical environment for teaching programming and it's a CMU project too.
If you don't recall, Randy Pausch was the Director of the Alice project.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
When I was in highschool, a friend asked me if I was interested in taking an extra-curricular course in PL/1 with him. I thought about it, and decided that by the time I got into the workforce it might be dead.
Four years from now, several of the technologies you mention will probably not be dead; but they may not be hiring newbies either. Four years? Even though tech is a lot more mature now, that's still a long time.
Academics is at its best when it sticks to the things that don't change. Teach the students stacks, queues, lists, structures, and yes even objects. Teach them in a language-neutral way. When they get out, they'll recognize these things in whatever flavor happens to be popular that year.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
If they are going to teach about abstraction... couldn't it just be extended to implement OO? What's the conflict at all? Besides, people can do OOP with parallel-functional languages such as Erlang too - just in a not-so-conventional way. Nobody says OOP must be implemented in the language level with all the boring words like "class", "inherits" etc...
OO is no more difficult than the calculus that freshmen have to learn - the argument that OO is unusually difficulty\crazy is moot.
Most of the programming co-ops that CS students will apply to will be OO programming - so the argument that CS students shouldn't learn OO early on, is also moot.
Finally OO programming is not dead, in fact, OO puts the OO in GOOD.
While I agree that OO programming isn't needed and even complicates some things. I have to say that OO programming is something the really needs to be taught early on.
OO programming is not so much a a method of programming, as it is a way of organizing data. And data organization is the fundamental purpose of Computer Sciences. To remove OO programming or just make it optional, is the equivalent of training a carpenter without ever teaching him to use screws. Sure he can get by with a hammer and nails. But for many projects he will be crippled having to do things the hard way, or use complicated workarounds to accomplish some fairly easy OO tasks.
Note: I also don't advocate that the reverse be done either. Where you teach only OO programming. (this is what I believe Java attempts to do) This is just as bad if not worse in many ways.
Wow, you said that and got modded up. Times are changing. Nearly a decade ago, someone posted this link and tried to defend why OOP was bad. He was mocked soundly, including for the battered Spock image. Unfortunately I couldn't find that story.
"First they came for the slanderers and i said nothing."
I think OO is still quite relevant because of the design methodologies that have grown up around it that help you model real-world problems. Like UP, for example. So when other methods of modeling problem domains come up around certain languages (or alternatively produce certain languages) that catch on and show that can do as well or better in modeling real-world problem domains than current OO languages and the design methodologies that presume an OO paradigm, I'll be on board. Until then, color me skeptical of the OO critics.
If you can't figure out how to unlock the extremely valuable aspects of OOP, then you have no business in the CS field. I've built objects to wrap API's that have solved more problems than using sequential-oriented programs. Every used Model-View-Controller Programming? Talk about Powerful. And is all OOP-based.
Is this really different from the Berkeley Intro to CS (CS61A) being taught around Scheme before getting into Data Structures and OO (CS61B) in the second semester? I think the third course in the series(CS61C) is C and assembly. I think this has been the case since 1989 when I graduated. http://www-inst.eecs.berkeley.edu/~cs61a/sp11/ http://inst.eecs.berkeley.edu/~cs61bl/sp11/ http://www-inst.eecs.berkeley.edu/~cs61c/sp11/ MIT only switched to Python from a similar curriculum upon which the Berkeley one is based a few years ago because of a robotics API and they wanted to standardize the intro course across different majors, I was told.
Making everything OO is silly. 50% of programming is simply to simple to benefit from being OO. Another 10% needs to be to optimized for OO. That other 40% is probably the reason we should teach OO. But we shouldn't teach just OO. It's school - you should teach all major programming models.
What most schools need to do is teach their students how software goes together in the real world. You get all these CS grads that can write little scripts but when faced with putting together something complex they completely fail. Syntax is just syntax. If you grasp the basic concepts you can figure out the syntax but if nobody teaches the concepts your not going to succeed. Highschool is a better place to teach programming concepts anyway. If you don't get them before college your probably not going to get them. I'm sick of schools pushing through CS grads that are totally unsuited to it.
Yes it does. OO is a general programing technique. Programmers in certain domains may choose not to use it, but that's a purely culture thing
So far in my studies, I've been learning about making my classes as generic as possible just for the explicit possibility of finding use for it in another project
It's a myth. Attempts to make as many of your classes as generic as possible will lead you ultimately to the dreaded ill-conceived in-house "framework".
Required reading for internet skeptics
I'm very glad I managed to make it through Carnegie Mellon's CS program (graduating in a month!) before this change. All of my introductory courses were taught in Java, though apparently the freshman last year switched to Smalltalk and python, without any focus on object-oriented programming. I'm not sure if it was a good or bad thing to be taught object-oriented programming first. I've been told that I write C++ and Python with a "Java accent," but in my opinion, this just makes my code infinitely more readable and modular than it would be otherwise. At the same time, I've had employers complain that I've abstracted too much of my code with OO to improve readability at the cost of a large amount of performance overhead. However, OO is just such a useful paradigm that can be applied to so many useful things, that I think its a shame that our department is no longer going to focus on it.
There is a lot of middle ground between making everything OO, and throwing it out completely. I think that it is important enough (if only due to sheer prevalence today) to be a required study. Sure, put it alongside Scheme (or Haskell) and Erlang for more breadth.
And the claim that OO is "both anti-modular and anti-parallel by its very nature" is plain silly. The whole point of OO is modularity, and parallelism is only an issue with non-encapsulated mutable state; but you don't need mutability in OO (see also: Objective Caml).
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.
True i wasn't saying it doesn't have its uses but it (OO) is abused in areas where it doesn't really add value and try doing OO on a PIC12F1822 :-)
I experienced this in college. Our introduction course at UIUC used Scheme on NextStep workstations. It didn't go well. Many of my classmates were livid. They viewed FP and Scheme as useless. "A recruiter laughed when he saw Scheme on my resume", was one comment I recall from the frequent rants about the subject on the course newsgroup. A few were completely perplexed. The average score on the first major exam was horrific and jarring - and this is in a top-tier CS program. Additionally, unless they chose an AI concentration, this course was the last time these students used FP. My guess is that a number of otherwise talented individuals became, at the very least, disenchanted about Comp Sci or even computing as a career, because of their experience in this class. Was that FP/Scheme learning curve/speed-bump/road-block really necessary? I guess the faculty decided "No" : By 1996(7?) the course was overhauled, and they switched to Java.
As an alumni, I don't think it's a good idea though. I guess they are trying to replace 15-111 with functional programming. The most important concept for programing I think is the ability to think systematically. The best first step IMO is to learn procedural programming. Yep back to the basic. No designing crap. That's the most natural way to think about programming. This is more for people other than CS major though. Probably worth half a term. Smart ass CS frosh are most likely to skip this course and take 15-2xx anyway.
The design of OO is covered along with various data structures and algorithm in 15-211. And 15-212 cover functional programming and 15-213 cover system programming stuff. These three course are most likely the pinnacle of programming aspect any CS major (Mathematical aspect is covered in some other courses). Course number may have changed now.
At least the TeX User's Group doesn't take three years to implement a new version
"I can't think of anything specific about OO that makes it poorly suited to parallel programming." - by msobkow (48369) on Saturday March 26, @08:30AM (#35621216) Homepage
Agreed, 110% - especially in a language that uses multiple threads & has thread-safe components. About the ONLY thing I can think of that "blocks parallelism", is when you have a process or data that doesn't allow for it, ala:
A = A+B
B = B+C
(That's one example, perhaps NOT the "best" one, that shows that much which I speak of... i.e.-> You cannot put A, & B on separate threads, because A has to wait on B completing its result calculation, first, etc.)
---
Again on this note of "modularity"? I agree with you as well, & I truly AM "confused" here myself:
"Apparently the meaning of "Modular" has changed since I was in University back in '82. OO used to be the epitome of modularity." - by msobkow (48369) on Saturday March 26, @08:30AM (#35621216) Homepage
Right on, & I went to "U" first time 84-88, & then again 91-92, & lately again 09- this summer to finish (gotta get the coins together ontop of taxes/utils/bills etc.-et al, to finish)...
Heck - on this note, in fact?
Well, I always THOUGHT that objects where absolutely useful in modularity... even more than separated utility class units, & especially on relatively "LARGISH" projects!
(Like you see in "Enterprise Class sized systems", of which to date professionally, I've built almost 30 now in my time professionally in the MIS/IS/IT end of things).
APK
P.S.=> I've never claimed to be "the greatest programmer", because I honestly do NOT believe there is such an animal... only harder & more focused + experienced workers with data &/or processes involved more than anything else which might make you 'great'... this? Takes time & experience imo... I can "get the job done" is my "personal estimation" of my self here.
So, perhaps these profs. & their "grounding in theory" (more than actual practice" professionally) is where this is coming from... pure "theoreticals" (which ARE helpful, I am not going to say they're not - collegiate academia saves you YEARS of work that way in mistakes or trial & error)...
In fact, I feel it saves you from Edison's "1% inspiration, 99% perspiration" because with a GOOD algorithm & some thought? You cut that "99% perspiration" & frustration, to probably 40% @ most, imo @ least! apk
There's a difference between not starting with object oriented programming and turning out computer science grads that have never been exposed to object oriented programming. The former is just fine. The latter is just stupid.
I guess it's the difference between whether you're turning out software engineers or whether you're turning out programmers. A programmer might only need to be able to understand a specific language or language family. A software engineer should be have a firm basis in every common language family, be it procedural, functional, object oriented, etc...
Support SETI@home
So far in my studies, I've been learning about making my classes as generic as possible just for the explicit possibility of finding use for it in another project
Which makes the point of GP. You're trying to solve problems that don't yet exist, and that are not in your specs. That's what I call bloat.
I'm not talking about creating a library. A library should proactively allow reuse and be as generic as possible.
Plus, your provisioning of multiple, imagined, potential, uses drags one into creating one-size-fits-all. Imagine everyone does. Crazy. How is that modular?
Think about print_helloworld. You do a method print.print_helloworld. Fine. What for? Because you also have printleft.print_helloworld printright.print_helloworld and printuppercase.print_helloworld and printlowercase.print_helloworld, or print.lowercase.lefttoright.print_hello_world and so forth?
Modular would be print_upper (print_righttoleft (print_helloworld)).
"You cannot put A, & B on separate threads" - by Anonymous Coward on Saturday March 26, @08:07PM (#35625916)
Aoologies to anyone who reads this, I have not been expressing myself well lately... that should have read "it's not PRACTICAL to do so, in separate threads"
(No gain results)
APK
I like many other programmers that have been around for a while have seen this come full circle again. I remember when Turbo Pascal became more OO and in my teens I spent a summer learning how to develop less procedurely and more OO. At the end of the summer I re-wrote a lot of code and in the end thought that it wasn't worth it. I know a lot of developers who develop procedurely in a OO language. While that frustrates me when I have to work on their code, it does show that OO isn't the only way to get the job done. Similarly is architecture, I code using MVVM like it's a religion. Hardly the fastest and most productive way to get something done, but at least when someone has to work on my code, they know where to find what they're looking for. May God help the poor soul that has to dig through my old FORTRAN code.
Just one student?
First of all, Bob Harper is one of the leading programming language researchers in the world, so let us cut the man some slack. He has been working on programming languages and logic since the 80's, so this isn't some new fad he read about in a magazine and then decided to try out on a whim. People like to slam researchers because they can't do anything practical, which might be true sometimes, but I can assure you that Bob can code. Saying that CMU is dumbing down the program because he wants to teach something closer to the mathematical foundations instead of specific tools or OO is just so wrong that I don't even know where to start.
Why the language designers of other popular languages have chosen to conflate the module system with the objects themselves is a mystery. Bob Harper knows what a proper module system is, he's one of the designers of Standard ML.
Can you suggest a method to teach undergraduates so that they can take this large blob of mud and clearly see that there are several orthogonal concepts hidden in there, and there is no inherent reason that you have to bunch it all together, effectively making it impossible to have modular non-objects?
You are conflating implementation inheritance (bad) and the type system bits that are necessary for multiple inheritance. At the type system level there are no fundamental problems with multiple inheritance, but it gives you plenty of rope to shoot yourself in the foot with.
Perhaps programmers can not handle multiple inheritance, and should never ever be given the option to have it. Another wild idea is that perhaps programmers should have other tools than just subtyping and objects in their language, and apply each tool when they have a problem that fits the particular tool.
Personally I hate it when my carpenter brings out the chainsaw to fix the nails that are coming out of my wall. I'd much prefer that he used a hammer for that particular problem instead.
And OO is not a complicated extra of programming, it is a simple ideology that makes programming so much easier when you know it.
I'll admit that OO does make programming easier in the long run. Though to do it right, you MUST spend a fair amount of time planning before throwing down that first line of code.
However, OO is just not suitable for all programming tasks. I currently work with an app that processes over 70,000 transactions per second. I doubt I could get a tenth of that performance with any OO language. Even in C, I spend quite a bit of time looking for ways to cut down on the number of conditionals, etc, since eliminating just one IF statement in the right place can get me as much as a 5% performance increase.
I fully agree that one should learn to program well procedurally FiRST, before tackling OO. If you don't have a firm grasp of that basics, you will never reach your full potential/
Your experience seems to reflect a general observation I have: "OOP is difficult to get right". Maybe it's grand and wonderful when you do get it right, but how to find "right" could be a long and winding path.
There are too many ways to do OOP wrong and not enough time-tested guidelines to flag those wrong ways to put one back on track.
Maybe OOP is the building block, the atom, for some greater new idea or paradigm. But until that second layer comes along to tame the current OO jungle, people will continue to turn gray trying to get current OO to work for real-world problems.
Table-ized A.I.
Central Michigan University isn't that important anyway.
Try to use some more complicated template, make some unconscious mistake, and then try to find out at runtime WTF the error message means!!!!!
First: Templates are not OOP. That doesn't mean you cannot use templates with OOP, but they are as much OOP as C++ ints are OOP (you'll nevertheless use them in OOP in C++). The most template-heavy part of C++, the STL, is exactly the opposite of OOP (while OOP combines data and operations, STL separates them as fas as possible). Indeed, one of the primary authors of the STL, Alexander Stepanov, has publicly expressed his dislike of object orientation.
Also note that the templates you'll use in conjunction with OOP will typically be extremely simple, and thus not give you those complex error messages. It's when doing generic programming, generative programming or template metaprogramming when you write complicated templates and thus have to deal with those error messages.
The Tao of math: The numbers you can count are not the real numbers.
The extremest form of emphasis on OOP in teaching CS, objects-first, as seen, for example, in Kölling's Objects First with Java, has been heavily criticised lately in the computer science education community. One recent visible critique was Moti Ben-Ari's Objects Never? Well, Hardly Ever! (PDF, unofficial version to avoid ACM paywall), (paywalled official ACM version).
Similar things are happening at my own university, where objects-first has been seen as an important preparation for future programming work. The CS course for engineering majors who won't be doing any more programming switched from Java to Python and covering OOP briefly at the end of the course; the CS course for CS majors and others who will be studying more programming is due to do the same this autumn.
Holy crap. I just spent ten minutes on that site without detecting a topic sentence that sets up statement of solution to follow statement of problem. The guy is relocating another fence post in every paragraph—without tending any livestock. All auger, no cattle.
I can do better in an off-the-cuff Slashdot post.
Thesis: there are many programmers out there who are religious about the ODR (and rightly so) but couldn't give a rat's ass about the OPR (one predicate rule).
The OPR has roughly the same importance in grappling with concurrency that the ODR has in grappling with consistency. By OPR violations I mean those sloppy loops where a predicate in the main loop control is spelled out again either before or after the loop to clean up a left-over fence post (of the N+1 kind). Often it's just i < MAX or something as simple and one repetition doesn't seem to do much damage. Often it's
complex_guard && test_expression (consumption_side_effect_expression)
so it's ugly if more of this is spelled out twice for a second time in a reiterative loop. Often, it's something as simple as i < MAX, but it should have been as ugly as the second case. Honey, contact Charlton Heston on the Ouija board, I'm changing sides.
My bug production rate went from low to exceptionally low on one reading of one chapter of one of Dijkstra's books: if I can't throw a dart at a page of source code, then mentally construct a correct expression for the number of times that execution point is reached (as a function of suitable variables representing the initial condition) then I'm doing it wrong
I also believe in single loop entrance, single loop exit, so to achieve this condition, I have to work for a living. There are few viable solutions under these constraints, and none without clarity, sometimes by means of a profusion of well-named boolean variables (that transcend almost to literacy).
CMU is onto something here. I'd replace everything I know about OOP with one course on how to write a formally provable exception-safe generic container with iterator: OOPS 101.
If only Dijkstra were alive today, he'd write one acidic chapter of one acidic book on the subject, and I'd be enlightened forever.
In my toolkit, OOP is good for exactly one thing: eliminating ugly repetition of manifest switch-case statements (ORR: one roundhouse rule), if it can't be resolved at compile time through genericity.
I am all for things like "objects" for non programmers to create code with, but those modules should have solid code behind them, and until we have true quantum or parallel computing, object oriented code is not ever going to be optimized. Processors still process sequentially, so the code to run properly and to understand good coding should be taught that way. This is similar to the CompTIA A++ cert dropping the need to know DOS to get the cert. If you even BUY the idea that "certs are good", dropping DOS from a diagnostic standpoint is ludicrous. I know people with the “whole boatload” of Microsoft Certs who could not find their way out of a paper box. And have the customer skills to match. C++ is a bastardization of the “C” language and always will be. It rides on the solid reputation of “C” as does “C#” and any other derivative. When the I/O and basic tenants of a language are changed, then it is no longer the language. Call the language something else like “D” “C"s predecessors were “A” and “B” at Bell Labs. If these “NEW AND BETTER “ solutions truly are, then give them a new name and let them survive or fail with them.
"Any sufficiently advanced technology is indistinguishable from magic." - Arthur C. Clarke
Oh I agree that you do need to know about OO but from the comments on similar stories on here and stack over flow it appears that a lot of CS degrees are turning out programmers and not rounded software engineers.
I've always considered OO programming to be an example of modular programming. True you have to remember "inherritance" and relationships, but it sure beats having to program the basic routines in C that are already done for you.
I wouldn't say that they're equally clear, especially if you're used to languages which don't have these operators. In Python for instance, ++x; and --x; are accepted but effectively no-ops (two unary operators chained), and x++; and x--; are syntax errors. If you see the latter for the first time while reading C, clearly there's something you don't know happening, rather than some conversion along the lines of +x or !!x that just throws away the result. Also, if you're switching between C and Python, and you use ++ by mistake, you want it to be in the place where it causes a syntax error, not a silent no-op.
Also, usually the variable is to the left of the operator that assigns to it (hence lvalue). So we have x = x + 1, x += 1, and x++; ++x breaks the pattern.
But it doesn't reduce total code size nor repetition. It just changes the repetition into repeated "lists" of same-named methods. It's still repetition, just re-sorted differently from verb-outer-noun-inner into noun-outer-verb-inner.
Switch/case statements often get a bad rap because the C-family languages have a very ugly and primitive switch/case statement. This is a language defect, not a paradigm defect. Why it's not modernized, I don't know.
Further, excessively repeated case/switch statements are often a symptom of poor design.
And they morph better into non-mutually-exclusive choices when change leads that way. It's harder to make the same change in OO.
Table-ized A.I.
Agreed. In fact Scala has introduced Parallel Collections with version 2.8 that allow looping methods on parallel collections that spread the work of the iterations across multiple processors and handle the partitioning of the work automatically. Very cool stuff.
Signatures are a waste of bandwi (buffering...)
When i first learned about OO and the animal object that could be used to hold a cat or dog object, and that you could inherit from the mammale object, etc,etc.....meow, bark, walk, run....we all know the way they explain it (if they do it well), and I thought, it was so simple, you could have shown me this in 7th grade and I would have understood it easily....advanced polymorphism can only be applied when you know the basics, but getting the basics down is now a high school level if you ask me...and all could benefit from this too.....
Thanks for the post. I like /. because of things like an off-hand mention of Sapir-Whorf - which I had never heard of by that name.
I would argue that the complexity problem must include all sources of complexity, which includes little things like testing, documentation, user instruction, correctness accounting. Rather than select a single axis of complexity, in this case the language, It makes more sense to consider all sources, and select a language/methodology that minimizes the overall complexity of the project.
If I can do a task in 3,000 lines of Forth, how do I compare that to the 30,000 or so lines of C++ that might be required to do the same thing? (Forth solutions typically are 1/10 the size of C++, according to Chuck Moore, an admittedly biased source.)
So with such a possibility, why am I stuck with a bazillion lines of C++? because there is more to software than coding, and more to the solution of a problem than SLOC.
I think the reason Forth is such a niche language is because it does not lend itself to generic solutions, rather the Forth dictionary paradigm tends to capture value by defining very specific language that may not reuse. (You say PotAAto, I say POOtato) this means that Forth tends to generate complex dictionaries of specific solutions that differ at an atomic level from the same use in a different context. This is a good news/bad news concept: Once you understand the dictionary, you understand the entire app, but to understand any of the app you typically have to understand the entire dictionary.
In the context of the article (teaching fundamentals to freshman) It would probably serve better to use a more generic vehicle than C++, where the fundamentals can be isolated and demonstrated with a minimum of syntax, and there are plentiful examples of well-structured code to learn from. My personal preference is for TCL, where the typical 'Hello World' program is:
puts "Hello World",
which is about as simple as it can get for syntax. This allows the student to concentrate on concepts rather than parenthesis.
if you look at the actual curriculum, freshmen learn Alice, which is an object-oriented teaching language; the blog author may have served on a committee that recommended his pet paradigm (FP) but it hasn't actually happened yet!
15 years ago some of us had anticipated that move: http://web.me.com/fbourdoncle/page4/page8/page8.html by Francois Bourdoncle, founder of Exalead
apparently CMU grads have better things to do than read slashdot.