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).
I forgot one important caveat though, which the summary neglects. "TFA" states that OO is "anti-parallel by its very nature," but does not explain how or why this is so, and indeed, my own experience is that this is complete hokum. A well-designed program can be parallelized regardless of implementing code; let's not forget the idea of computational equivalence. This is not to disparage FP and other such "rational" languages as I would have to agree that implicit parallelization can be a major feature -- but how about some love for Erlang in all this?
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?
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.
I don't know about *starting* in assembler,...
Why not? What better way to start a CS program than learning how to program an actual computer without all the abstraction? And then go to some mid-level language like 'C' from there and then a higher level language from there - all the while implementing data structures and algorithms in those languages: like parallelism.
Languages are just syntax of an abstraction of the processor instructions and it pains me when I see posts about how one language is "better" than another for a particular job or the "right tool for the job" - we're talking about CS NOT carpentry.
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.
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.
well if you teach bad OOP then yes, if your good at teaching it and you pick as sensible language (for simplicity) or use good patterns... then the problems mentioned are solved by the very thing they claim is inherently against it.
thank God the internet isn't a human right.
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*
We're back to the discussion about the "scientific education" vs. "trade schools" rift again?
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 point of a university Computer Science course is not to train students in iPhone development.
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.
Yes, but how do you create a transistor? Do you just buy one?
I think all studies should start from scratch - throw you on an island and let you invent calculus yourself. What's the point in progress if you can't explain it to a 10 year old in two sentences?
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."
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
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, but CS departments are not supposed to be ignoring the real world either. The fact that almost my entire CS degree in the early 1990s was taught via C and Scheme provided me with a good theoretical foundation, which has indeed made me adaptable and served me well over the course of time. But such a focus can made finding that first job quite painful; I was somewhat lucky. When you don't have $LANGUAGE_OF_THE_DAY on your resume, it gets circular-filed before interview, even when you come from a top-15 undergraduate school. It makes me cringe, but I actually find myself doing this circular-filing myself, as my small company cannot absorb the pain and expense of training up a newly minted CS student on the toolchains, languages, and libraries that are actually in use in the business world.
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...
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.
Ironically, I find it vastly easier to encapsulate my mechanisms for parallelization in objects :).
Loading...
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.
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.
And I can say for sure that at the university of Waterloo (the leading school for software engineering in Canada, by far) OO is still the leading thing they teach freshmen programmers/software engineers.
Troll is not a replacement for I disagree.
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?
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.
If you are going into a programming course in univ you probably already know at least the basics of programming.
And OO is not a complicated extra of programming, it is a simple ideology that makes programming so much easier when you know it.
Troll is not a replacement for I disagree.
Admittedly I never designed my own processor (I only got as far as taking a few introductory chip design courses) but yes. I'm working on getting my university diploma (the only below-doctor degree Germany used to have) and I was exposed to a variety of languages over the course of my studies. C was mandatory, as were CSP, PROLOG and Haskell, even though the university was nominally Java-centric. C/C++ was used in a lot of courses, not just the basic "this is how an OS works" ones. (Assembler was only briefly touched on, though, as a side sbject to formal verification of program code.)
Now they've switched over to a master/bachelor system. When talking to people studying for the new degrees I'm horrified. The curriculum is essentially fixed, there's minimal choice and you can get a BSc without ever being exposed to any language other than Java. Yeah. That's going to give them deep insight into how programming works.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
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
If you are going into a programming course in univ you probably already know at least the basics of programming.
You'd be surprised. But that is not a bad thing. Ideally, CS should be to programming as physics is to engineering. It's called a science after all.
Truth arises more readily from error than from confusion. -Francis Bacon
Well they cannot model the course after the 1% who don't know anything.
Troll is not a replacement for I disagree.
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.
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.
Carnegie Mellon University. It's one of the best schools in the world for CS.
Required reading for internet skeptics
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.
When someone's talking about applying a tool to solve a problem, as opposed to coming up with new ways to solve problems, she's not talking about computer _science_. It's closer to carpentry or, depending on the scale, engineering.
Truth arises more readily from error than from confusion. -Francis Bacon
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
the alpha nerd does 90% of the work and the other 4 team members offer worship and keep the ramen coming.
Haha I remember being the alpha nerd... :-(
"When information is power, privacy is freedom" - Jah-Wren Ryel
In order to be "employable" they need to know fundamentals as well as those modern languages. Those that're just taught OO actually have gaps in their knowlege coming out of college and think in a "just so" way like the parent says- and it's noit "all good" for what the business needs. Many of the high profile failures seem to stem from OO-only thinking.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Either use a physical board or a simulator (I seem to recall there is one of those as part of the GCompris suite) and build different logical gates out of wires, switches and some lightbulbs (or chainsaw/lasers/fricking sharks if you get more kicks out of it). Once you've done this you will actually understand how a modern computer actually works. The difference between what you built and a real world processor is quantitative.
"DRM is like the Ford Pinto: it's a smooth ride, right up the point at which it explodes and ruins your day."-C.Doctorow
Yes, but how do you create a transistor?
You look over the shoulders of Jeri Ellsworth and imitate.
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
You have to know both.
Yes, Assembly isn't well suited to solving problems in it. But then, you are not learning assembly in order to better solve problems (well, unless you need the last bit of speed which you cannot get even from decent compilers, but that's the rare exception). You learn assembly to better understand how your solutions in a higher level language will be executed on the computer. You learn to understand why certain ideas which look nice in theory are just non-starters in practice. You learn to understand why it matters what is your outer loop and what your inner loop, even though your algorithm doesn't depend on it. You learn why the order of the fields in your data structures may matter.
The Tao of math: The numbers you can count are not the real numbers.
Strange, I seem to have managed to hold down a job in plain old C for a while now. Never have done any OO since university. Never needed it.
Not everything is written in Java. Or C#
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
Well, if over 15 years of coding, plus a Master's degree in CS has not made me "see things in assembler", I wonder what would. It's just a completely strange way of modelling things when it comes to formulating Turing-complete formal solutions to problems, which is what programming is.
In algorithmics (where I more specifically got my degree in), asymptotic complexity beats architectural details every time...
And yes, I do consider Knuth to be overrated :p
I want to play Free Market with a drowning Libertarian.
I have to agree. My High School was a joint one for two towns, and had ~800 students total. My junior and senior year I applied for the VB course. I was told to pick another because there wasn't enough interest, and with all my other college(school had general, college, honors difficulty levels) preparation classes I had no time at home. College English 12 had four ~15 page papers with one a summary analysis of three works by an author(I was able to do mine on Arthur C Clarke at least) you analyzed. Of course, since I couldn't take VB I had honors French(I had two study halls used to get most of the general HW done to work on my papers at home.)
So I went into college having experience with computers, and being good with math and science. I just had not gotten a chance to program due to school budget and personal time constraints.
To be honest, you don't need to program in HS. If you come out with solid math and science skills you do fine. Programming is very easy, but requires math and logic skills.
Go, Objective C.
I agree. A CS major or programmer might need to know the concept of how the machine does the work, but has no need to be proficient at it. It is like telling a structural engineer that he needs to go work in a iron ore mine before he can appreciate how to calculate torsional loads. Don't CS grads have to write a compiler to get their degree like they did in the good old days? That's really all anyone needs.
Not to mention, and I hate to be this guy, it is irrelevant. Thousands of people have labored furiously for the last 50 years to make computers more usable. Programming languages are the result of people wanting to focus the work on problem solving, not on how each computing architecture prefers to have its ear nibbled. These people wracked their brains trying to make it so the people after them didn't have to know that the 13th register of pentium IIIs made on Jan 21, 1993 is flaky and shouldn't be used. My job as a programmer is to transform some input into some other output. If I need to model a process, I shouldn't have to go out and chop down a tree, mash it into pulp, build a paper making press, press out a bunch of paper, dry it, perfect it; just so I can draw a flowchart. The "perfect" programming language is one that most closely matches how people think and divide up processes.
Though I would submit that OO programming is NOT that. Writing the words "make 10 copies" onto the piece of paper in front of us does not magically make 10 copies appear in the literature holder in Denver. Maybe it is because I learned in BASIC and Pascal and C, but the scope jumping possible in OO programming makes me crazy, and causes bugs. Of course it is easier to directly poke some other thing within some function, but it creates webs of complication that add misery to lives. That's why I like the UNIX way- everything has an in door and an out door.
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
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
It might model the problem space, but it doesn't model the solution space.
We will always need some people to write the optimizing compilers to match the two ... and some of us just need the performance and work with relatively simple algorithms, trying to internalize a functional programming language and determine the imperative (ie. real world) program flow in my head just gets in the way.
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)
You should note how in recent updates interpreted and compiled languages have had syntax and semantic extensions in order to assist with the concurrency and parallel problems. C++0a for C++ immediately comes to mind. Scala and Clojure both run on the jvm, so their programs may use java libraries and objects, but they use functional paradigms first and foremost. The problem with objects is mutable state, which means extra and complex overhead is required in order make sure that each thread, which may not bring the object into scope in the exact sequence the programmer intended, still gets with minimal delay the appropriate version of the object for reading or writing.
I daresay the faculty at The University of Waterloo are thinking about this.
Now, this is still the First College Programming Course problem. MIT a couple of years back changed from Scheme to python. The bright kids who are admitted to top CS schools have written lots of code before they arrive on campus. The top CS schools will still, in the course of the undergraduate program, teach OOP, procedural, assembly, and functional programming approaches, compilers, formal languages, discrete mathematics, and data structures. The freshman language is an implementation detail.
I can't remember a single job post 2000 that required a graduate to build their own processor, or write in assembly.
I know those jobs exist, but they are a tiny percent of the market. There are tons and tons of programing jobs in the world, and the vast majority of them don't require that type of knowledge. Is it good to have a basic understanding? Sure. Especially when it comes to memory. But is being able to write assembler going to make anyone better at writing LOB apps?
If I had to choose between an applicant that had assembly classes or technical writting classes, I'd take the one with the tech writting classes almost every time, all other things being equal.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
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.
I'm not sure I understand; solution space is how you put the things in your programming language together to solve the problem. The closer the language makes this already, the better. All Turing-complete languages are computationally equivalent; the asm solution is not any more "real" than, say, a Scheme solution, performance considerations aside.
Compiler authoring is its own niche problem domain; there, one needs to use assembly. After that is done, you just use the compiler to solve other problems.
Also, imperative program flow is not "more real" than a functional-programming language definition of a function... that's a mindset problem that takes a lot of effort to break down (been there, done that, seen the light). Actually, a functional-programming version often demonstrates what the problem is about much better, making you think better about how to solve it.
I want to play Free Market with a drowning Libertarian.
Exactly, so they should all learn Occam :p
Using objects is not the same as OOP.
Required reading for internet skeptics
This "programming is an art" and "college isn't a trade school" stuff is bullshit.
What is college for, if NOT to train someone in the workings of some area of learning? I mean, that's what the degrees SAY in their names. Bachelor = apprentice, master = master, doctor = master of masters.
And art. Art is the skillful and creative use of some medium. A guitar player has to learn to play the guitar before he can demonstrate his artistry. A brick layer has to learn how to lay bricks in a structurally sound manner before he can make a beautiful arch. And a goddamned programmer has to know how to program before he can create anything approaching artistic.
Just slapping some shit together and having the luck that it comes out looking good isn't art. Art is having an idea and having the skills to bring that idea to life. You have to know the rules before you know how to break them.
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.
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.
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 doubt I could write anything past a basic calculator in assembler, but it's been proven several times I could code in circles around some of those that call themselves programmers. By far the most difficult thing I've found in complex non-OOP code is the memory management of inits and cleanups. If you change a code's path and somehow miss a cleanup step, you get memory leaks and seven kinds of hell. You always have to make sure all the t's are crossed and i's are dotted. It can be done and everything written in C in proof of it, but it's not for the faint of heart.
To be an object is primarily a self-contained entity that can clean up its own mess. If it has children, it should also tell them to clean up their mess so that I can delete just the top level object. This is the essence of the QObject in Qt. That also goes for any file handles, network sockets, database connections and whatever else it's holding onto. In the real world, I do have state. If I try connecting to a network, there will be a delay and unless I want to block everything I have to buffer the data I was going to send somehow until the connection is ready. If the connection fails, I have to clear out that data. What when someone trips over the network cord? If the client clicks an "Abort" button? If I have timers that I need to wait for? I have to respond to such things and you're about to reinvent the event loop.
I'm not sure what the deal with parallelization is, I've managed to use both worker/queue and thread pools to deal with that efficiently. With signals and slots I've never felt that my applications were so modular in any other language as they are in C++/Qt. They have their inputs and outputs but otherwise you can rearrange the pieces pretty much any way you want like a bunch of legos.
Maybe it's not the style for the 10000-core supercomputer, but I think you get very, very far just being skilled at using what you have. I think the analogy of tools in a toolbox is wrong, it's more like writing a book half in English, half in French according to what language you feel expresses it the best. The result is mostly that a) very few understand it and b) they don't work well together. That said, there's a helluva lot that can be improved about OOP languages.
Live today, because you never know what tomorrow brings
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...
Perhaps you mean not the same as OOA/OOD, but relating to OOA/OOD - of course not, but you can obviously extrapolate my meaning in that I find it quite easy to manage concurrency and OOP in my designs.
Most mistakes in parallelization, irrespective of what type of programming you use, are related to where in your abstraction you plan for it. People usually pick the wrong level. There's nothing about OOP that is anti-parallelization.
I'm no OOP fanatic either, it's just another tool in the toolbox.
Loading...
As far as I'm concerned, starting CS students with OO modeling is appropriate and I am disappointed in CMU in eliminating this from the freshman curriculum. Why? Because they need to start learning the discipline of thinking about computer constructs as things and not strictly abstractions. To think about how they are structured, behave, and interact. I've been doing large-scale distributed, parallel, and highly available systems for over 20 years, and with OO modeling, some of the stuff that I and my colleagues have accomplished would have been, quite frankly, impossible. Modeling helped identify pernicious race conditions, determine what programming abstractions were appropriate (a storage adapter abstraction, for example, so the same user code could store an object in a local database using one storage adapter type, and in a remote server using a bus storage adapter type - which is a configuration option, not a programming one), and what elements may have platform-specific issues. When the resulting work product is 10M LOC, and has to be delivered in 2-3 years by a small team of programmers/engineers, modeling helps resolve a lot of issues very early on in the design process. So, in my opinion, CMU has just dropped off of the top of the CS education institutional list, and I speak as one who used to teach for CMU in their professional education division, the AIPE.
Sometimes, real fast is almost as good as real-time.
> Don't CS grads have to write a compiler to get their degree like they did in the good old days? That's really all anyone needs.
Most. Useless. Class. Ever. Learned *nothing*. It was just "implement X. Here is the design of X. You must implement it this way."
It would have been much better if we had at least just been told "Implement X" and had to figure out how. As it is, the only thing we were able to do to make it slightly more tolerable was talking the professor into letting us do it in C++ instead of Java.
The class where we learned assembly and machine design and microcode was better. So was the VLSI class. Compilers not helpful.
-- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
Actually that sort of stuff is more "magic" to me.
Especially when it stops working. Then you have to figure out why the heck it doesn't work.
That kind of stuff is like:
1) Do stuff
2) Magic/miracle happens
3) Result you want.
I think many of us nerds know that miracles are very very rare and we're interested in how the heck the stuff works, and how it typically stops working...
I think you need at least a basic understanding of it. Of course it makes not much sense to write a business application in assembler, but how do you know where you CS students wind up? When they wind up in kernel development or embedded programming, or even in processor development or PLC programming, there is not much they can do without knowing assembler.
Of course no one "needs" OO. It merely produces superior software by permitting more powerful methodologies.
Brian Fundakowski Feldman
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.
Using OO to develop a Turing-complete formal solution would require a Turing-complete description of the OO library you are working with, which would be a very surprising thing to find. The other possibility is that you are working on truly trivial software.
Too high a level. Solve the problem with only NAND Gates and some bits of wire.
Actually most CS folks and programmers in general could badly use a lesson in the hardware underneath it all. Does not mean you should toss out programming languages though.
"TFA" states that OO is "anti-parallel by its very nature," but does not explain how or why this is so, and indeed, my own experience is that this is complete hokum. A well-designed program can be parallelized regardless of implementing code; let's not forget the idea of computational equivalence.
Of course you can write any kind of code in any Turing-complete language. However, every language "encourages" people to code in particular styles. OO "encourages" the use of opaque stateful objects, which are by default not threadsafe. Making every object threadsafe is a massive undertaking and a drag on performance (for example, Java's collections libraries tried this route at first, then gave up on it later).
Functional languages "encourage" keeping all state on the execution stack, which by default *is* threadsafe, and some of these languages encourage tail recursion and map/reduce instead of loop constructs, and these can often be automatically parallelized.
So that's great for problems that fit well into a functional model. However, IMO, the object model seems to more naturally fit many real-world business problems than the functional model, which is why it's far more popular today. That may change if the only way to improve computing performance going forward continues to be adding more parallel CPU cores.
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.
Silly OP is clearly joking, he knows there is one meaningful anagram: `cum`.
Which means `with` in Latin. Problem, anglocentrists?
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
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
Then you are not a very strong programmer at all. Assembler is necessary to understand exactly how a processor works, and how well any given algorithm will work on that architecture.
Last I heard, the world didn't need a lot of "strong" programmers. They needed a lot of good ones. You don't need to know assembly to be a good programmer. There's a lot of coding that goes nowhere near the level of abstraction of assembly.
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.
Knuth is probably one of the worst examples you could have picked. I've had to screw around with Knuth's TeX code (which is his primary programming work) before. Beautiful output, but the complexity and sheer treachery of the code is staggering. He breaks so many common sense rules (such as making code modular), it's surprising that the code is almost flawless in its execution.
I'm not sure you got my point, or otherwise I'm just missing yours. To make things clearer, what exactly is it that you disagree with in my statement that programming is the act of formulating solutions to problems using Turing-complete languages?
I want to play Free Market with a drowning Libertarian.
So you can't call yourself an english major if you can't read Sumerian cuneiform?
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.
Assembler is useful for solving some problems, for example establishing whether an approach is in fact deterministic, and not just in theory. It's also useful for debugging, proofing compilers, embedded stuff with tight requirements etc.
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.
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.
The article said that OO wasn't suitable for a CS curriculum, not that first year students aren't suitable for OO.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Perhaps assembler is necessary to understand exactly how a processor works. But understanding exactly how a processor works is not necessary for development of most applications. Heck, understanding the underlying frameworks/libraries you are utilizing often isn't.
Some company wants a great website. They want to hire you to make it. 'How a processor works' as more than a vague understanding isn't going to help you make a great website.
How about working on some specific real world fields, such as writing interconnect drivers and such for HPC, or extremely tight requirements in some fields of embedded stuff, such as telemetry gear, both networked and autonomous? Or just proving in fact that something is deterministic, instead of just in theory. Or verifying that the compiler is indeed doing what it should.
And as for architectural details being dwarfed, then you haven't been working with porting things between different architectures. An algorithm that yields excellent performance on one can be 2 orders of magnitude slower on another. Which should be right up your alley, namely of developing and selecting the right algorithms etc.
Around here, the C programmer is probably getting paid more and also have a plethora of offers any time he is looking. The OO programmer is going to be asked trivia questions about the default configuration of Struts 2.3 files or the MS C++ equivalent in a never ending series of interviews for big companies that don't write anything interesting.
The C programmer is probably pursued by a headhunter who knows what they want, the Java/C# programmer is typically pursued by a recruiter who will be some vapid grad who looks good and has no real skills.
It's two different worlds really. Sure all you Java/C# programmers can tell me how it is different for you in particular, but observing the process the last two years the C (and often C++) jobs were consistently better. Again I realize that C++ is OO, but that comprises about 1% of the difficulty of programming C++. If you're coming out of college and a company is recruiting for a C++, they'll train you if you come from a C-teaching university. In fact, they'd prefer a C-taught student over a Java/C# one any day.
t
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.
As a CMU student who heard from a professor who shall remain unnamed, the future of computing doesn't lie in "parallelization across a single resource," but massively parallelizable computing, or distributed-resource computing. OO languages are not great at that as message-passing has massive overhead when serializing and deserializing. Thus, in the interest of the "future" they're moving away from OO as a freshman course, and instead leave it for the more specific courses. (15-211, etc).
That could be all speculation by the professor who shall remain unnamed but it also could be that the silly drama students have to take a programming course and they have no use for OO so they're dumbing it down so that not all the drama students fail. I suspect the latter.
Strong is equal to good in this case. And I see many who style themselves good, but can't understand when a program of theirs works well on one processor, but not on another. Sure, they may be "good" inside their specific niche, but they have no versatility in their problem solving.
As for Knuth, he's showing that he is indeed a good programmer. Just because something is modular does not explicitly make it good code, nor does it being non-modular make it explicitly bad code. IKEA furniture is modular. Masterwork furniture is less modular. But which is made by the more skilled craftsman?
Modular is a crutch, that works well in some general fields, but are unwieldy or even a waste of resources and a roadblock in other fields.
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!
The world needs a lot more guys who can lay tile using best practice materials and approaches than the world needs guys in a lab trying to invent a better mortar.
Or maybe Scala
Troll is not a replacement for I disagree.
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
"Perhaps assembler is necessary to understand exactly how a processor works. But understanding exactly how a processor works is not necessary for development of most applications. Heck, understanding the underlying frameworks/libraries you are utilizing often isn't."
And then we are stuck with the endless bloat, endless patchwork with messy kludges that are in constant need of fixing....
My Uni course involved Assembly, Pascal, VHDL and C++. It forced a certain knowledge on how a computer works, I finished university 3 whole years ago and have been involved in training up new graduates for various projects. Almost all of them have only done Java in university, the result is they never understand basic concepts like pointers. Which would be fine but you need to understand pointers in order to code in Java (since it has them).
Having a basic understanding of the fundamentals is what a degree is all about, you also seem to think a person would either do technical writing or assembly. If your looking at a Software/Computer Engineering course the candidate should have done both since engineering involves everything from the design phase through to support and testing. Otherwise all the person has done is a software developer or technical writing course.
I do agree with CMU in that teaching how to write modular code is important, I love C++ but prefer Java because most old C++ projects I've worked on (and some are 15 years old) start out as modules but always turn into enormous inter-dependent blobs.Eclipse's plug-in approach seems to help keep dependencies to a minimum.
Also, imperative program flow is not "more real" than a functional-programming language definition of a function...
I understand how that is true, in a sense, but in another very "real" sense, your processor is imperative. Function calls are just a clever trick played on you by your compiler, your standard library, and some assembly macros.
(Well, unless you're running on a Reduceron or something.)
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.
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.
Last time I checked, HTML isn't a programming language...
Shiny. Let's be bad guys.
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?
If you consider using frameworks and libraries 'endless bloat, endless patchwork etc....' then sure. We'd have that. The end product is easier to create and easier to maintain and the cost of development/maintenance significantly out-weights the near trivial cost of hardware capable of handling the endless bloat (in most situations).
If I need a new kitchen floor, I don't want to hire a guy who has the all of the knowledge and experience required required to make the tiles, underlayment, mortar and grout from scratch. I *certainly* don't want to pay that same guy to make custom tiles for me, use his home-brew underlayment material, his redesigned mortar, and his new formula for grout. The cost would be outrageous. And I don't care how much 'better' it might be; because the existing best practice methods for installing a new tile floor are enough to last for the next 50 years.
Keep in mind, the industry knowledge and best practices we have now were built upon years of use from the leaders in the industry. Just 'knowing' assembler isn't enough to derive the rest. If you need to learn the rest anyway, you could just learn the rest, not learn assembly and say, 'I'm going to do what these other people say is the best for reasons I only vaguely understand" and be just fine. In fact, in most situations, you'd be significantly ahead of the guy who spent that same time learning assembler while you were learning Java or C#.
No, trust me, they probably already have some other higher level paradigm lined up, perhaps functional. While I may disagree with OO being anti-parallel (have they never heard of thread classes?) and anti-modular (WTF? what are classes if not modules?), I can see how they might want to start students out on something simpler or more straightforward. For a little better understanding into this mindset, see Object Oriented Programming is Inherently Harmful.
Nathan's blog
Last time I checked, nobody said anything about HTML.....
ASP
ASP.NET
PHP
PERL
C
Flash
Javascript
AJAX
Java
Coldfusion
Silverlight
etc....
Maybe if you had read the article, you would have seen this: " 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." It doesn't sound to me like CMU is interested in making OOP a mandatory area of study. It also doesn't sound to me like it's going to be taught at the junior or senior level either, based on the tone of that statement.
I like my women how I like my sugar.. granulated.
It's a "library" if you call it from main(). It's a "framework" if main() calls you.
I hate frameworks.
Of course no one "needs" OO. It merely produces superior software
Having a laugh, are you?
Required reading for internet skeptics
Nope. Linux is NOT OO. Windows is NOT OO. Apple's OS is NOT OO. OS2 is OO, but is extinct.... BeOS is OO but is also extinct..................
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.
Does not mean you should toss out programming languages though.
Definitely not. It isn't an either-or choice. But abstractions like pointers and malloc in the C language make a lot more sense if you have written at least one or two well-structured assembly language programs. Instead, further abstractions are often spun up to make the concept of pointers even MORE remote from the actual hardware.
Are you actually suggesting that CS majors should only learn one way to write computer programs? Where did you go to school, Java U.?
Do daemons dream of electric sleep()?
Well, if over 15 years of coding, plus a Master's degree in CS has not made me "see things in assembler", I wonder what would.
Sounds like it's too late for you.
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.
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).
Bull.
There are other SW development jobs out there that absolutely do not require OO. In fact I would be very reluctant to hire anyone who have done OO and framework based stuff most of the time. To clarify: Our SW devs are firmware developers who work with embedded devices that get all of 2-8KB of ram and 16-128KB of flash to play with. Devs that rely on libraries and frameworks will never be able to get the job done.
On top of that I will still require your code to be understandable and reusable.
Modular is an approach that lends itself well to ant-farm type operations. It means that the coders themselves are pluggable modules, and can be recruited and fired at will.
It's an important part of the world, but it's not a particularly innovative part of it. Somebody else has to set things up 'just so' so the little worker ants have the proper little nuggets to move around.
Superior how. Do you fit your code in a smaller memory footprint, can you you make it run on a slower clock, using less energy? If not I am not interested in your so called 'superior code'.
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.
Modular, for example, is necessary because software is not just about getting something once that works, it's also about maintainability, extensibility and the like. There are other requirements that must be factored in when architecting a piece of software. For embedded software on, e.g., memory constrained devices, you might have to use hacks and other weird tricks just to get it to work. It wouldn't be considered good programming in other contexts, but given the constraints and requirements of the software, it's the optimal solution.
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.
Is understanding assembly going to make you produce PHP code that's faster and lower on memory usage? Probably not a whole lot. PHP is bloated and if you are using it, your stuff will be bloated one way or another. The best you can do is make efficient use of PHP to reduce that footprint. Knowing assembly tricks won't help you at all.
Definitely. There is always a need for more worker ants. More people in production than in design.
If that's what you choose as your role, all power to you.
That all depends on what you consider interesting: solving a problem, the way of solving a problem, or the way of solving the solving of a problem. None is "more important" , "more correct" or "more real programming" than the other.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
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
The fact that almost my entire CS degree in the early 1990s was taught via C and Scheme provided me with a good theoretical foundation, which has indeed made me adaptable and served me well over the course of time. But such a focus can made finding that first job quite painful; I was somewhat lucky. When you don't have $LANGUAGE_OF_THE_DAY on your resume, it gets circular-filed before interview...
Weird. I circular file J2EE, XML frameworks, etc. For a fresh-out-of-school candidate, C + Scheme goes to the top of the good pile: one language that proves you known how a computer works, and one that deals in elegant abstractions.
Then again, the interviewee had better actually have something to say about those languages. "Oh, I just used it in a course" does not count.
You do the equivalent of 'creating a transistor' in your physics labs. Then you progress to the course where you build a flip-flop circuit. After that you might start to be taught design at the level of logic modules, TTL gates, etc.
It doesn't really even have to be a linear progression. But your understanding does need to 'flesh out' so that you eventually can grasp the issue all the way down to the electrons.
Well, no, it doesn't. There is a huge need for Telephone Sanitizers and always will be. Just not on my space ship, please.
programming is the act of formulating solutions to problems using Turing-complete languages?
So... it's not programming if you're not using a Turing complete language?
Perhaps you should have paid more attention while earning that MS degree.
And yes, I do consider Knuth to be overrated :p
Looks like a case of the Dunning-Kruger effect.
Required reading for internet skeptics
Modular is a crutch, that works well in some general fields, but are unwieldy or even a waste of resources and a roadblock in other fields.
And meticulously crafted software is also a crutch, a waste of time and resources, and a roadblock in some other fields. What exactly is the argument here?
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
A number of years ago, I worked on a team that developed this 500,000 line FORTRAN program for the analysis of scientific data. The code was very modular, but the data was all over the place. A change in the data in one part of the program could cause unforeseen problems in another part. Object oriented programming helps prevent this problem by organizing the code and the data it acts upon into objects. In my experience, object oriented programming is one of the biggest programming breakthroughs since higher level languages. I just can't see an institution with the reputation of CMU deprecating this methodology.
"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
I remember always picking one of the useless fucks from the back of the classroom to be my lab partner, because they would then stay the hell out of the way.
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
Programming main requires an insane attention to detail, since getting any detail wrong will cause the program to either crash or develop security holes. Most people aren't monomaniacs, so most programs are full of bugs.
Managed environments help, but don't solve the underlaying problem: any error causes completely unpredictable behaviour, rather than a few hiccups the system could recover from. We know that Turing powerful systems can degrade gracefully: human brains are (at least) Turing powerful, yet drunk humans can still walk - not a gracefully as when sober, but can anyway.
Now, the question is: how do you make a system where errors don't cause a cascade failure, as they do in current programs? How do you build a system where programming errors are more like a badly tuned car engine than Chernobyl meltdown?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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.
The world needs a lot more guys who can lay tile using best practice materials and approaches than the world needs guys in a lab trying to invent a better mortar
Sure, but that doesn't mean that MIT should gear its material science program toward the guys laying tile using best practices. CMU's one of the top 3 computer science programs in the country; their curriculum isn't geared toward turning out programmers.
rage, rage against the dying of the light
As a recent CMU alum, I can testify that the Java language is not stressed by any means at the University. There are 2 introductory programming classes that are Java based. If you scored a 4 or 5 on the AP computer science exam, you can get credit for 1 or both of these, respectively. Java is a perfectly acceptable programming language to begin learning with. I studied it in high school and was able to pass out of both of these classes, so I took C classes next. If one has a solid understanding of the Java language they will see that it is in fact very similar to C, and any C class should be a breeze. Then there is an algorithms class (15-211) which is Java based. After this, every other standard undergraduate computer science class is not Java based, but more focused on systems/functional programming (if one wishes to take a programming route). After freshman/sophomore year, you will be hard pressed to find significant Java work in a CS class. Note that the above was true when I attended CMU, things may be slightly different now.
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!
As a chemistry major back in the 70s, we had to take chemistry and other hard science (as opposed to soft science) classes in the first two years, so that by the time we were upper classman, we were in a position to take the hard hard science classes. Many people drop out of chemistry (usually pre-med) because the work was too difficult. Those that had an aptitude for it and persevered, became chemists.
It is interesting, that in a program that claims to turn out Computer Scientists, CMU would not be doing something similar.
Why not? Because invariably they'll base their curriculum on X86 which is the most blasphemous instruction set in the world. F*ck you Segment offsets!!
Bye!
How? How do you do parallel programing using OOP??????????
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
You will find even less demand for functional programming or imperative programming. Hopefully other schools won't follow this loon's lead, because we will have to import even more programmers (or offshore) from overseas.
I don't understand what you mean by "C-teaching" university etc.
Do universities *really* teach these languages?
When I went to school, we were taught Turing in first year, and were told straight-up that we would never use it in the real world. It was a fine language for exploring CS concepts, having easy (pascal-like) syntax and support for abstract data types.
In second year, we were taught Miranda, SmallTalk and Prolog. Quickly, all in one half-semester course. We learned just enough of each programming language to write programs in each of the functional, object-oriented, and logical programming paradigms. These weren't hand-holding courses, either: basic syntax and ideas were explained, after that it was pretty much RTFM for details.
In third year, we had a digital electronics course that required us to interface with our VHDL projects in C. Nobody taught us C, but there were tutorials available for the hopelessly-lost. We were expected to learn the language on our own. I don't know if the tutorials were any good or not; attending would have affected my party schedule.
In third year, we also had a software engineering course that taught client-server architecture using X11 as a model and discussed object oriented programming design. We were expected to be able to write a simple GUI application in C++ using X11 base classes, and to override bits of one of the widget toolkits to do something or other.
I've had a successful career programming in many languages - mostly C. I didn't need to learn how to write program in C in school; I just needed to learn how to write programs.
IMHO, anybody who thinks a university should be teaching them a particular programming language should probably be going to a community college. I RTFA and I think CMU is on the right track. And given the quality of all the CMU grads I've ever had the pleasure of working with, I'd have to say that whoever is running their CS program is doing a really great job.
Do daemons dream of electric sleep()?
And then we are stuck with the endless bloat, endless patchwork with messy kludges that are in constant need of fixing....
So what is your proposal? We go back to producing non-portable code close to the metal? There are reason many smart people have spent the last 50+ years abstracting away from the machine level.
Computers are usually better at handling the low-level details than humans. Hardware has exponentially grown more powerful, cheaper and plentiful such that the programmer's time is a lot more important. At the same time, software requirements has grown ever more complex. And finally, computers are our slaves, not the other way around. Abstractions are to make life easier on us.
Computers would be just as "happy" if we fed them 1s and 0s. But that's notoriously hard on humans. So we started abstracting away from that, beginning with assembly. And even in the 50s when you really, really need to squeeze every bit of performance out of those slow-lumbering beasts, people were working on 3rd generation languages. Many assembly programmers thought there was no way Fortran could produce assembly code that would run as well as hand-written code. But they were wrong.
Try to use some more complicated template, make some unconscious mistake, and then try to find out at runtime WTF the error message means!!!!!
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.
Hard drive? If they're not playing Doom on Jacquard's loom, they're just wannabes. Sure the frame rate sucks, but this is about keeping it reel [sic].
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
As far as I'm concerned, starting CS students with OO modeling is appropriate and I am disappointed in CMU in eliminating this from the freshman curriculum. Why? Because they need to start learning the discipline of thinking about computer constructs as things and not strictly abstractions. To think about how they are structured, behave, and interact
I guarantee you that with the freshman curriculum moving to include functional programming, the students will be thinking a lot more about structures and interaction than in any freshman-level OO course. You can't avoid thinking about it when you're programming in ML (which CMU uses for most of their functional stuff).
rage, rage against the dying of the light
That's why Carnegie Mellon's computer science program has such a poor reputation in the field.
Sounds a lot like my last year of high school, if you add 3 advanced math classes, but I still found the time to take a computer course and work part time as a programmer for a small firm.
I've found people head down two paths when they start out in IT. The first group has a real curiosity about everything related to computers and usual end up being the techies that keep IT departments working. The second group are people who an interest and a bit of attitude but quickly get overwhelmed by the day to day demands of IT work. They usually end up getting out of the pure technical roles and move towards more management type roles within a few years.
Because of the extremely technical nature of the job it requires a true passion for the work to be successful. If by the time you get to university you don't have more than a basic (no pun intended) proficiency in programming then you're likely headed for a non-techie role.
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
And most programming solutions require this because ... computers are too slow today? Lacking in memory? Compilers don't produce optimized code that's usually better than hand written assembly?
This attitude, coupled with the horror show that is the state of "modern" programming languages, is the reason that we have so much shit software that uses ridiculous amounts of memory and runs slower than Rosie O'Donnell.
Required reading for internet skeptics
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.
What? Where are you getting your information. If you examine the assembly code generated from a C program (/FAs option for VisualStudio, -S option for gcc, etc), you'll see that the entry point to the program is exactly at "main". Any C runtime initialization is performed when/if it's needed. In fact, if your program does not link in any C runtime calls, the executable will contain no "runtime" at all. This is no different than if you had coded the program in assembler and named the your entry procedure "_main" and set the entry point for the linker to "_main".
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
Yes it produces more powerful methodologies, because of the synergistic effects that objects have with modern cloud environments.
You forgot "enterprise". You need to include the word somewhere in the sentence or management won't take you seriously.
Intron: the portion of DNA which expresses nothing useful.
the very first sentence in TFA states it's because 2 professors have fallen for the "functional programming" methodology to solve the parallel processing problems caused by poor OS design in a multi-processor(or core) environment. By believing FP is going to solve all the problems, they're pushing it on the very young and impressionable to further the belief.
As others have stated, an entry level course excluding much or any OOP concepts could be justified easily with the fact that underlying OOP and other methodologies are the methods/procedures. Starting students with a procedural foundation gets them a solid foundation first without mixing in much or any abstraction layering methodology also.
By claiming FP is the reason they show their bias right off the bat and the motivation for the course change. IMO
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
Actually, with the addition of CSS3, HTML5 has been proven to be Turing-complete
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.
Not everything is written in Java. Or C#
... or ruby, or python, or javascript, or objective C, or C++. oh, looks like we are covering a lot of ground with that statement.
the only places where OO languages are not dominate are situations where you can't afford to step back from the bare metal (OS internals, firmware, device drivers, etc). in other words, if the environment permits OO, then it dominates. that might say something about what developers prefer and what works best.
As much as people hate to admit it, the ratio of actual innovators to implementors is STAGGERING. Even really great, successful, smart people, haven't contributed anything of value to the knowledgebase of the field. That's not a bad thing. Most college professors, even with their published papers in magazines nobody reads and their awards haven't. Even most really successful developers and architects aren't doing anything other than implementing best-practice solutions to really common problems.
The real test shouldn't be whether or not you look for 'new ways to solve problems' but whether you *can* find *better* ways to solve problems or whether you can find solutions to problems that haven't already been solved. The number of people who can honestly say they've accomplished either of those things is unbelievably slim.
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
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.
You say that like it's a bad thing. Yet a person who is "somewhat proficient" in assembler will likely have a mental model of how a modern computer works, that, while possibly less wierd, is no less incorrect. And it's is even more difficult to reason about how most nontrivial "programs" work by trying to "think like the machine." Moreover, to the extent this is false, the programs tend to be either trivial, or else difficult to design and maintain.
Once you know how the machine works, then you can start studying abstraction.
Given that the machine is a highly layered system of abstractions, this strikes me as a naïve and even dangerous philosophy from standpoints both theoretical and practical.
C.f., e.g., Parnas' remarks on your approach — under the heading "why conventional software development does not produce reliable programs" — "this intuitively appealing method works well," he writes, "on problems too small to matter."
With that said, I suspect we agree more than we disagree. To wit,
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.
I agree completely. And it's even worse to treat OOP as synonymous with "abstraction," given that the problems with OOP are not that it encourages"abstraction," rather that it very frequently seems to lead to the wrong abstractions! But students' learning less about how to build the "right" abstractions doesn't strike me as a good solution to this problem.
In fact, the less practitioners know about "abstraction," the more likely they'll have little choice but to use "pre-canned abstractions," and in a very bad position, moreover, to evaluate vendors' claims that the "Frobozz Magic Framework(tm) v10.0" (incorporating even better "best practices") is not only both a floor wax and a dessert topping, but in fact the solution to all possible problems.
This is hyperbole, of course, but your "square peg, round hole" comment is quite on-point —I spent years working with developers, consultants, etc., who seemed to see programming as figuring out how to "adapt customers' problems to the latest solutions," and nearly always had a "solution" in mind before they knew anything about the problem. This led to things like "projects" like replacing perfectly workable Perl-driven Web applications with Java applications that were not only buggier, but orders of magnitude slower, to boot, because "Perl doesn't scale," then, when performance became a probem, suggesting a rewrite to enable a "multi-tier architecture" that included "Web acceleration front-ends" (read: proxy servers) to cache static pages, rather than forcing the application server to generate each page dynamically.
The reason why the Perl code was much faster than its replacement was that it only generated dynamic content once, so nearly every request was simply served by Apache out of the application's "content cache," guaranteed to be correct since the appropriate bits were purged automatically whenever new data arrived.
When I pointed this out, I was flooded with questions about whether it was "designed with future applications in mind." When I asked what future applications were in mind, none were, so I couldn't answer the question, of course. But given that the whole thing, modulo Apache itself and mod_perl, consisted of maybe 500 lines of code and was written in the course of a couple weeks, if, given some "future application," the answer wasn't an unqualified "yes,"
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!
This surprises me, most schools didn't become Java happy until about 2000-01 or so, I know I avoided the switch over by a few years and I started my BS in 2000. Prior to Java, most schools were teaching C++ without exposing the students to classes and such.
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.
I took asm, it was required. Granted it was VAX asm, still taught the concepts.
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.
Group work in schools usually resulted in one doing all the programming since the rest well, simply didn't know how to program. Its a joke how many folks working towards a computer related degree struggle with it.
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
I went through two years of CS courses at a university as a math major. They used Java as the language and frankly, it was the worst choice for beginning programming students. Its too modern, teaches you to be sloppy (with the whole garbage collection thing) and does not give you a good understanding of how a computer actually works. When I took C programming classes it was a much better course, as you had to be careful with memory allocation, pointers and such and the language is only procedural based, which makes more sense if you are in Calc I or Precalc over objects to a freshmen. Even though I don't know any assembly, I believe it would have been the best choice for a freshmen intro to CS course followed by a class in C. Java should only be a class you take as needed.
That brings me to an interesting point, / . is just "the ramblings of socially-inept, technology-literate news-mongers".
Assembly should be taught to every CS major yes, but its more useful to the Computer Engineers. A good CS dude is partially a mathematician and as such they think in functions and operations (i.e. procedural language).
That brings me to an interesting point, / . is just "the ramblings of socially-inept, technology-literate news-mongers".
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.
If you are going into a programming course in univ you probably already know at least the basics of programming.
Anecdotal, but from many interviews, that's about all most have when they're done with the univ too.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
Modular is a crutch, that works well in some general fields, but are unwieldy or even a waste of resources and a roadblock in other fields. And meticulously crafted software is also a crutch, a waste of time and resources, and a roadblock in some other fields. What exactly is the argument here?
It also gives you less job security, since if your code is easily understood and extensible, they can hire someone else at a lower wage to add on to it with ease.
That brings me to an interesting point, / . is just "the ramblings of socially-inept, technology-literate news-mongers".
Sure, there are problem spaces where the efficiencies of straight "C-style" procedural programming are warranted just like there are problem spaces where C is too inefficient and assembler is warranted, but for the vast majority of problem spaces the ability to abstract away the details is absolutely necessary to achieve a reasonably maintainable application, which, at least as I read it, is how the term "superior" is being applied here.
Companies can spend $$$ on highly trained programmers squeezing every bit of performance out of the existing hardware by optimizing low-level code, or they can spend (usually less) $$$ on increasing the performance of the hardware by another 5 or 10% to compensate for the overhead of supporting a less efficient, but easier to maintain OO implementation. Given the ever increasing hardware performance relative to cost trend, most companies opt for the latter.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
"Perhaps assembler is necessary to understand exactly how a processor works. But understanding exactly how a processor works is not necessary for development of most applications. Heck, understanding the underlying frameworks/libraries you are utilizing often isn't."
And then we are stuck with the endless bloat, endless patchwork with messy kludges that are in constant need of fixing....
1.) "Messy Kludges" -- I spent several years as a chief architect of a company in charge of maintaining and improving a 10 million line legacy codebase for a large organization. In my experience messy kludges result from people who ignore OO principles, not from people who ignore assembler ones.
2.) I agree there is basic value in understanding how a processor works, especially if you're writing RT or NRT apps. If you want to highly optimize a program, being able to visualize a bit about how many instructions you've put into the loop you're repeating a million times is a good thing... But honestly, IME most of the optimization is understanding how data is vectored onto the CPU, and how the L1 and L2 caches work, these days. Furthermore... I met one of Intel's top assembly writers once. I don't remember the exact numbers, but I think he said something like he matched the compiler 85% of the time, the compiler beat him 10% of the time, and he beat the compiler 5% of the time....Increasingly the compilers optimize code so much better than humans could, that I really fail to see why actually knowing assembly well enough to write it is helpful.
Sure, they may be "good" inside their specific niche, but they have no versatility in their problem solving.
I don't buy that assembly language programming gives you that insight. At high level programming, you're far more likely to be affected by varying quality in the platform dependent parts of your environment than on the nuts and bolts of the underlying CPU. Sure, it gives you options (like some ability to troubleshoot a flaky device driver) which could be better than nothing.
Just because something is modular does not explicitly make it good code, nor does it being non-modular make it explicitly bad code.
Non-modular code, on the scale of TeX, is a strong indication of bad code. Anything that breaks the rule of local change, local effect is going to be much harder to maintain.
That's odd, because I live in Ca and the first 5 CS courses are Algorithm Design, C, Assembly, OO in C++, and Data Structures (in C++) which is the last class I completed last semester. I took a Java class just because I could but it does not count towards my requirements for graduation. I wonder how different the requirements are for a CS degree across the country, it seems much more varied than I would have expected.
Except, of course, that with modern processors assembler is really a highly abstracted virtual machine running over the actual hardware. The modern processor typically has multiple pipelines, out-of-order execution, and a greater number of general-purpose registers than is made available by the instruction set.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
I'd have to agree. Even if one chooses to implement using a procedural language, OO analysis is extremely useful in understanding who does what to the data, when and how.
Isn't CMU the home of SEI? The authors of the Capability Maturity Model? Back when I was with Boeing, our information systems (IS) people insisted that all* in-house s/w projects be developed using the CMM. Their (Boeing's) interpretation of the CMM turned out to be total garbage. But to top it off, when we (engineering) suggested that the actual authors of the CMM (that would be SEI) be brought in as consultants to help manage a CMM pilot program, the IS manager responded with, "SEI just developed the model. They don't actually have any experience doing software development".
* 'All' included engineering managed projects, but they allowed certain exemptions from the policy. Namely s/w project developed by Boeing IS.
Have gnu, will travel.
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//
I've found people head down two paths when they start out in IT. The first group has a real curiosity about everything related to computers and usual end up being the techies that keep IT departments working. The second group are people who an interest and a bit of attitude but quickly get overwhelmed by the day to day demands of IT work. They usually end up getting out of the pure technical roles and move towards more management type roles within a few years.
Have you been doing IT for very long? I've been at it for fifteen years at this point and I have always enjoyed the technical side of the profession. After a while, the newness and the gee whiz factor fades. In my case it had to do with being expected to be interested and engaged five plus days a week, on someone else's schedule and time line. Tech is great and fun when it is a hobby. Once you've been doing it as a profession for a while, the rate of change can wear you down. In case it is not that I got overwhelmed, I simply lost interest in being out there on the cutting edge and dealing with all of the headaches that come along with it. I took a realistic look at where I was and asked myself, "Do I want to be the guy dealing with the bugs of the latest .01 incremental release for the rest of my life?" In my case, the answer was no.
Once you've been through a few technology refreshes, your attitude shifts from, "Cool, new toys!" to "Here we go again..." I've seen people who tend toward two poles. They are either very helpful and enjoy helping others be better. Or they are arrogant, and derive self gratification from being the "smartest person in the room" and their ability to fix other people's "stupid mistakes".
At this point in my career I am enjoying mentoring people who are still excited about the technology, but who in most cases are such tech heads that they either do not see, or do not care about the bigger organizational picture. Being a pure tech employee is a path to high stress and always dealing with someone younger, who has less distractions (no family yet, etc).
I like the middle ground, where I understand the tech well enough to architect solutions to business problems, and then manage the implementation. I'm on my third iteration of that right now. Get hired, spend a few years getting everything dialed in and running smoothly, rest on the laurels for a little bit, get bored and move on to some place else where they pay more. Rinse and repeat. It has worked out well for my employers because the salary of someone who can maintain a system is less than someone who can build it from the ground up and/or identify and remedy major structural problems.
Err, easily? Java, style, you'd create a class that extends Runnable (or whatever it's called - it's been a while). When you create one of those and call .run() on it, it starts in a new thread. When the object is destroyed (and garbage collected), the thread dies with it. Nice and easy. Otherwise, you've got much the same concerns as in an imperative language; result gathering, locks etc.
He's probably coming from the context of entry being the point you tell the OS "i want to execute ".
I love to slaughter the english language.
Many of the high profile failures seem to stem from OO-only thinking.
I saw this first hand during a system implementation that eventually failed spectacularly (to the point where the team responsible for the project got fired). There were simply too many instances where the answer was, "We're waiting for the vendor to update the library / dll." Eventually someone in senior management said, "You are supposed to be programmers. Why is this entire project stalled waiting for someone else to write code?"
If all a person knows are libraries and frameworks, they are setting themselves up for failure. Sooner or later they will hit a wall that they have to climb over themselves. Without a solid foundation in a real language, they will be worthless when that time comes.
1% who DON'T know anything? You sure about that?
Usually (well, with gcc and linux, at any rate) there's a file called "crt0.o" that does initial setup (sets up argv[], maybe env[] and quite possible errno and funky things with alloca(). Once that's done it calls to main().
Red to red, black to black. Switch it on, but stand well back.
The basics; isn't that what PASCAL is for?
Codifex Maximus ~ In search of... a shorter sig.
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.
They chose... poorly.
You need not worry about that anymore nowadays, at least in C and C++. Recent compilers optimize the useless instructions out automatically.
Load register from memory
Increment register
Store register to memory
If post ++ then decrement register
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 ?
Yes, exactly. For example, in my view, writing web pages does not count as programming, as the language is not equivalent to a Turing machine -- which all the "real programming languages" are. Well, we don't have infinite memory, but still..
Basic stuff.
I want to play Free Market with a drowning Libertarian.
Well, here we have two opposing views of programming. On the one hand, we've got the Systems style programmer who can bootstrap a machine using binary digit displays and toggle switches. On the other hand we've got a Scriptor who uses canned programming.
There are pros and cons to both approaches:
The Systems programmer will take longer to do the job, assuredly. But, when he's done, the result will be tight fast efficient code that will get the job done in a fraction of the time a script could.
The Scriptor can probably hack together something that will get the job done but will not scale well. You'll need a supercomputer/Beowulf cluster to handle the load.
My opinion is: Use the scripting languages to prototype and make the final product a compilation like C/C++/PASCAL etc...
C++ is Object Oriented and it is also compiled. Best of both worlds.
Codifex Maximus ~ In search of... a shorter sig.
And yes, I do consider Knuth to be overrated :p
Get back to me when you have published 22 books plus the equivalent of the incredible TAOCP series, when you have about 50 years of CS experience, when you have the admiration of most of the educated, civilized world.
And, yes, I am a Knuth fan.
Circle the wagons and fire inward. Entropy increases without bounds.
Human behaviour is fuzzy, that is, there's a "good enough" approach to say... walking. As long as I am on my feet and "kinda" moving towards my destination, it is good enough. On the other hand, software tends to be very precise. I know of no customer of mine that would accept a program as good enough if it hit the database with the correct information 90% of the time.
What is very important though, as you already said, is the ability to recover from some error. This is no trivial task and requires lots of experience and attention to detail, especially as the components of the software grow in number and complexity. A good design is essential, and lots of attention to detail is needed. The problem is that customers are not willing to pay for that unless they belong to a small set of industries such as airspace or nuclear.
moi
You're employable if you can program well in *any* language IMO (speaking as a developer who has hired others). In fact, the more wild the language, the more impressed I am. :-)
And OS's may be object-based, but not object-oriented. Big difference.
Higher Logics: where programming meets science.
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
Where are you interviewing people from? I graduated in '07 and all the things that you bemoan as missing in new graduates were required. Two courses in computer architecture culminating in designing a CPU, with optional advanced courses that covered design of other components, such as DMA drivers and USB PHYs. The computer architecture courses also covered assembly programming, including having us reverse engineer programs and create buffer overflow attacks against them. The intro to programming courses were entirely C/C++ and were followed by a course in embedded control (in C) and a course in algorithmics (C++). There were also software engineering courses that required us to take common patterns and implement them in various languages.
I was not the only person in the program, nor was my alma mater the top rated school in the world. If you can't find people under the age of 30 who know this stuff, then odds are you're not advertising the job in the right places, or you're not making it sound interesting enough.
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...
(gp) Don't CS grads have to write a compiler to get their degree like they did in the good old days? That's really all anyone needs.
(parent) Most. Useless. Class. Ever. Learned *nothing*. It was just "implement X. Here is the design of X. You must implement it this way."
Sorry to hear your compiler writing class was a bummer. My compiler writing class was the most interesting class I took while earning my Master's degree in CS. The prof was spectacular, I learned a ton of stuff, and I later applied the knowledge when I wrote a cross-assembler and worked on several compiler projects.
Circle the wagons and fire inward. Entropy increases without bounds.
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.
In another very real sense, the processor is not imperative in the way asm makes it look like -- there are micro-instructions, parallel pipelines, the works. What I am trying to get across that as long as your formalism is Turing-complete,
And I hope that you do understand that by functional programming I mean something quite different from something like a C function -- it's not a clever compiler trick, but pretty much a whole programming paradigm with its roots in formal logic and math...
I want to play Free Market with a drowning Libertarian.
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."
If your program does not link in any C runtime calls, the executable will contain no "runtime" at all
If the executable doesn't contain the C runtime, it won't work at all, because the runtime contains the function which is the actual entry point, which is traditionally called _start on Unix (I can't remember if it's something different on Windows). This is why if you don't include a "main" function you'll get an error from the linker about an undefined reference - the C runtime refers to the main function in order to call it after it has performed initialization.
static initialization occurs before main(). I'm not talking about function-scoped "static", but real static initialization. Also, any function with __attribute__((constructor)) also gets called before main().
When you are working on a specific real world field, any of them, they present their real-world requirements which must be taken into account. This is software engineering.
Proving that something is deterministic has to happen in theory, and then robustly implemented in ways that preserve the logic of the proof. Anything else is folly.
This is a bit of an Engineering vs. CS debate at its core. I am not an "engineer", but more of a math-style CS guy, so for me it's both the asymptotic behaviour of algorithms that really matters, and there programming is not necessarily involved much if at all. What I am interested in programming, though, is in "how" we express programs in a symbolic way, and how that influences our thinking regarding the program and the problem solution it represents. There asm fails, IMO, and the claims of guys who think they see bits fly in the air Matrix-style as they code, seem suspect.
I want to play Free Market with a drowning Libertarian.
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.
The basics; isn't that what PASCAL is for?
That's precisely what freshman classes were taught in when I started on my CSci degree. I'm probably dating myself, though...
"Convictions are more dangerous enemies of truth than lies."
I suppose I should have read TACOP earlier in life so that the book would have had a fair shot of "educating" me from ground up on its own terms. As I am, I was a bit underwhelmed by how much pages he spends on things that are relatively straightforward. I'm not saying the stuff isn't "fundamental", it's just that I'm not sure it is particularly useful for an experienced CS type, and as far as teaching the "art" of programming, IMO, both the selected topics and the presentation would be different in my own version... which would probably be closer to Structure and Interpretation of Computer Programs :-)
I want to play Free Market with a drowning Libertarian.
There's a lot of coding that goes nowhere near the level of abstraction of assembly.
I suspect you mean "lack of abstraction"? Anyway, I disagree with the notion that for some weird reason, the "strongest" programming happens on the asm level and that it is the assembly itself that somehow, as a language, is special in the sense of gifting a deep understanding of programming in general. It's just a limited set of small instructions, and just because it is "hard" (in the "lot of work" sense), doesn't mean it's actually "informative" -- and as a thought experiment, I'm willing to bet a lot of money that a proficient high-level programmer is able to actually do something with asm when exposed to it, than a hypothetical asm-only programmer would be able to do only in asm. The building blocks for ideas are simply not present there.
I want to play Free Market with a drowning Libertarian.
But anti-modular? Anti-parallel?
Onda Technology Institute
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
If it's just you it's not dating, it's being a lonely old codger.
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.
So what if [java] doesn't compile to machine code?
Java does compile to machine code. The difference is that the compiler is part of the runtime and it only compiles code as it needs to. At least on all the modern JVM's that use Just in Time compilation.
you can freely use native types
This on the other hand is not true. You can't use machine native types. Even the primitive types are not native. Native types would not be portable. Even using the Java Native Interface you can't pass native types around.
Er, you know that markup languages don't encompass the whole of non-Turing complete languages right?
I'm starting to doubt your claim of a MS in CS...
Required reading for internet skeptics
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.
No true Scotsman, eh?
I outright laugh at people in an Interview when they ask me if I'll write OO code.
I bet you have to go to a lot of interviews, then.
OO code is worse than 10,000 jmp, or goto's. Code written in an OO "framework" produces an excessive of files, classes, and thousands upon thousands of useless objects that are not even necessary for the task at hand, almost as bad as XML, but worse. You end up with bloated apps, that cannot be read or understood by anyone quickly. Let alone have any of the code be re-usable anywhere else.
You're now arguing about various frameworks which suck. You're probably right, but you haven't provided any arguments against OO.
Here's how I think of it: objects it's about creating abstract data types that fit your problem, rather than solving your problems with a combination of raw char, int, and *. Most people seem to agree that OO also implies using inheritance and run-time polymorphism when there's a need for it. I don't know -- I very rarely see a need for that.
Incidentally, Standard ML (the language of choice in TFA) supports abstract data types, so probably the parts of OO which the CMU guys hate are the parts I don't use a lot, not the parts I find essential.
I seriously doubt McCarthy was concerned with exactly how an algorithm worked on a given processor while he was discovering an alternative computing model to Turing machines.
If you're thinking Lambda Calculus, it's from Alonzo Church, not McCarthy, although McCarthy's Lisp has its roots there. But theoretically, all of them are equivalent.
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.
Not to dismiss my earlier reply, but I couldn't resist passing this along:
HTML5 + CSS3 is Turing Complete
Neat, apparently Eli Fox-Epstein managed to implement Rule 110 in HTML5 and CSS3 -- check it out
I know it misses the point -- but it's absolutely hilarious given your last post.
Required reading for internet skeptics
Programming is a craft. You have to love doing it to be good at it.
Agreed. When I interview someone for a programming position at any level, I drill them on this more than I do on their technical talent and training. I can train anyone with talent, and I can quickly identify those who don't have talent. But if there's no passion for programming, then there's no reason for me to waste my time with the training, regardless of the talent level.
Being smart and having knowledge will not make someone successful, not without the right attitude.
Jhyrryl
(He's trolling. It's not worth it.)
No, but you do need to be able to read Shakespeare. Nobody is suggesting we practice using card readers or programming by hand. We need to go back far enough to understand what is going on, but not the truly archaic. (and no, undergraduates don't need to be fluent in assembly.)
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
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.
Uh, no. I'm defining programming languages strictly as Turing-complete ones, which is the class of the languages that we know to be capable of solving the problems we work with in automated computation... I don't understand what the controversy is in this statement.
I want to play Free Market with a drowning Libertarian.
OO is just another tool for programmers to use. It is by no means a panacea. I agree that it should be taught AFTER a class in functional programming and, perhaps, even after the student learns about how the computer actually works (assembler, computer architecture).
GC
Gregory Casamento
## Chief Maintainer for GNUstep
Ok, so I hadn't heard of that yet. Doesn't alter my actual point one bit though.
I want to play Free Market with a drowning Libertarian.
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?
After graduating in Mechanical Engineering I went into CS for a second degree. We learned C from day one in the mid-90s. Then we learned C++ and of course applied C or were offered to apply Fortran to Numerical Analysis and to see the varying differences. Unfortunately, we had no Objective-C. Had to learn that at NeXT. I agree that learning Java, C#, C++ are all bad decisions as part of one's first year in CS. Brian Cox was a wise man for chosing Object-ve-C as an OO version of C, not a better C with OO ala C++. With the emergence of C99 and soon C1x Apple has positioned themselves well with OpenCL and Objective-C with LLVM/Clang. At any rate, there is plenty of time for a CS major to learn OO. Applying theoretical mathematics with computation is far more valuable than becoming completely confused by a professor who doesn't know OOA/D, and a waste of money. They are better off learning that on their own.
A novice prefers the tools that he knows.
A tradesman prefers the tools he's most comfortable with.
A craftsman prefers the best tool for the job.
A vendor prefers an ideology.
You, sir, sound like a vendor or someone who has drank the vendor kool-aid.
OO is a good tool for a set of common problems. Trying to apply OO outside that set has resulted in more crap software than any programming fad/paradigm that I can think of.
*sigh* back to work...
Shows how one can make mis-assumptions when not all of the data is available... :-) That helps (using ML for functional programming), but I still think that OO analysis and design are proper subjects for early CS program courses. JMHO...
Sometimes, real fast is almost as good as real-time.
My professional title is "application administrator." If you have java code running on a java app server, I support it. Problem is, over my 2.5 year experience in this position, there are a lot of "OutOfMemory" issues that occur. There are also a lot of issues related to lazily configured hibernate causing database performance issues. And of course, the fixall comes from Windows ... "just restart it." Only very few Java developers could actually support the infrastructure they code for, that includes database, messaging and ESB backends.
If I had a shotgun to point at some developers, there would be an extreme shortage of developers.
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?
The idea since at least the 50s , if not earlier, was that unless you needed to target the machine, to focus on the problem at hand. And the best way to do that is by abstracting away
Yeah, we're long past the point where abstraction adds simplicity, we've been adding unnecessary complexity for more than a decade.
Just take a look at this example of reading a file and displaying it's contents to the console using Java.
What a waste. I stand by my earlier post.
Required reading for internet skeptics
You might be surprised to know that some of the students starting these courses have never touched programming at all. :p
Hell, in 2003 I had people in my class who had never used a word processor.... this was in a course-line on programming industrial PLCs.... scary
Those that're just taught OO actually have gaps in their knowlege coming out of college and think in a "just so" way like the parent says
Some truth to that. I had interns coming out of UCLA working on my project at Google who were not ashamed at all about using malloc as part of their per-function-call API. After squirting code like that all over the code base it took longer to get rid of it than it did for them to write it in the first place. Epilogue is, after converting it back to reasonably orthogonally, typical C code it also shrank in size by a factor of 5 or so and was orders of magnitude more efficient, plus maintainable, whereas in that sort of weird C++-in-C style it was nigh on indecipherable not to mention buggy. I was pretty shocked and wondered what kind of education these highly sought after interns were actually getting.
Note that I am not arguing against OOP at all, I get a huge amount of mileage out of it. I am instead arguing against mindlessly applying some idea like "new is OOP, use it everywhere" in completely inappropriate contexts. I am pretty sure they would have made the same mess in C++, just not as immediately obvious.
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
I suppose next you'll be arguing that using "goto"s is how we should all be programming.
I'll argue that, at least in the case where what you're writing is a parser for example, in which the most natural and efficient embodiment is a state machine directly implemented with jumps. In this case the goto implementation is also the most readable and easiest to verify because you can mindlessly map it back to your original state diagram. (You did write the state diagram before starting to code didn't you? Didn't you??)
Have you got your LWN subscription yet?
Linux is NOT OO.
You'd be wrong about that.
Have you got your LWN subscription yet?
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
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?
In my opinion over half of being OO is simply striving for understandable and reusable code (the rest being mostly unimportant specifies), personally I think you might have more OO-ish code then you think.
"Devs that rely on libraries ..."
lol, you don't like relying on libraries but you still want reusable code, isn't that a contradiction? If you can use a library to do something and get out of coding it again then you are simply reusing someone else's code, and why not?
Troll is not a replacement for I disagree.
I still honestly don't get your problem here. We have Turing-complete languages which are equivalent in terms of problems they solve; then we have more restricted languages that are unable to solve those problems (regexps, markup languages etc). As far as I know, we do not have programming languages that go beyond what a Turing machine is capable of solving. If you know of some, please let me know.
I want to play Free Market with a drowning Libertarian.
Not at all. For instance, interfaces can't declare type members. Well, they can in Scala, but Scala was designed with ML modules in mind. Every mainstream OO language was not.
Higher Logics: where programming meets science.
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?
I have been in freshmen programming courses and I know what you mean, I don't understand why they are their but their always seem to be a few.
But I am surprised about the word processor.
Troll is not a replacement for I disagree.
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.
Interesting argument, can you supply concrete examples of such state mutation?
Have you got your LWN subscription yet?
If there is a designer on the project who has derived his programmatic thinking only from asm and does not understand, for example, why functional programming conceptually matters, the whole project is hosed from the start and I'd prefer to steer clear of such idiocy... designers need a FAR more high-level, abstract understanding of things. And of course in the end you cannot separate the two roles; a developer will have to be a designer in the end.
I want to play Free Market with a drowning Libertarian.
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.
Ah, so you're a troll... no need to respond then :-)
I want to play Free Market with a drowning Libertarian.
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.
Bah, everyone knows that real computer users employ butterflies not needles.
You're a bit thick, aren't you? My point was that your definition was incorrect, as a programmer can "formulate solutions to problems" in a non-Turing complete language. Granted, only a subset of problems, but completely True none-the-less.
This painfully obvious observation turns your silly and unnecessary definition of programming into what you ultimately intended to say: "programmers formulate solutions to problems using programming languages"
Which is totally useless and a waste of time.
I know that you're very proud of knowing what Turing-complete means -- as you've used the term in virtually all of your other useless posts in this discussion (correctly and otherwise) -- but it's not unfamiliar to the Slashdot crowd, or to anyone who took an intro to CS course in college.
Calling yourself a great programmer and then unnecessarily denigrating Knuth makes you look like an ass. Add to that the incredibly stupid things you've said that make you look like an idiot, for example:
When you say things like this:
Why not work in a language that represents or helps formulate the problem-space abstractions better?
While going on about practicality you create a perfect storm of arrogance and ignorance that is hard to ignore -- it's like you're the best troll ever.
Required reading for internet skeptics
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.
I don't think that the GP suggested writing a GUI or a modern game in assembly. Or C. But I've met fresh graduates that did not understood the difference between passing a parameter by value an passing it by reference. Don't you think that such "programmer" is going to produce crappy code even if using C++ or VB.NET to write OO code? Understanding for example pointers or generally "what the fuck is going on" helps there a lot.
Btw did you see Days of Thunder? You can be clever, talented and all that, but only understanding what's going under the hood can make you excellent.
Could be worse. This is valid C:
Check out my sci-fi/humor trilogy at PatriotsBooks.
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).
Yes, I suspected you were after something like that while I assume you still understanding perfectly well what I was saying. Or maybe you don't.
You are still intentionally missing my point in all of my posts, though, and choosing to slander me instead on irrelevancies. For the purposes of what is interesting to the discussion, programming languages really are the Turing-complete ones, as they, if needed, will also encompass the lesser classes. It does not matter that you may actually use, say, a regular expression to provide a solution to a sub-problem in a program, or that you use finite languages in your enumerations, or in the set of your programming language keywords...
The point is that we have this class of symbolic languages that we know are equivalent theoretically, and within that class, we're free to choose a representation. I personally do not believe that assembly does, in any sense, convey any particularly interesting meanings to the programmer within that class. This is the reason why higher-level programming languages exist.
I am not sure how I could actually mention Turing-complete languages without sounding like I'm somehow "proud" of understanding of the meaning of the term. Sorry, but I can't avoid using it when its usage is appropriate.
I want to play Free Market with a drowning Libertarian.
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.
I agree with this. OO does have a place in system level programming. Years ago I worked on a complex networking driver for OS/2 (about 100,000 lines of C++) to handle ATM (Asynchronous Transfer Mode). The company I worked for also had a driver for Windows NT that was written in C. The C driver, by comparison, was 360,000 lines of code and tended to have a lot more bugs and was much more difficult to maintain.
The C++ driver was considerably smaller and faster and contained more functionality than the equivalent C driver. Performance was also excellent due to the way the data path was implemented.
I think C++ definitely has its uses and can be great for things like protocol stacks or where a lot of complexity takes place. It can be a lot trickier to work with C++, though, which I think is probably the main reason. C is a much simpler language than C++ and it's a lot easier to understand what's going on at the machine level without a lot of experience.
I think there's definitely room for C++ within Linux, though. I think it might be easier to restrict it to loadable modules and I recall that somebody once implemented a C++ framework for modules.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
I think there's definitely room for C++ within Linux, though. I think it might be easier to restrict it to loadable modules and I recall that somebody once implemented a C++ framework for modules.
No framework is necessary, just declare the external linkage extern "C".
Have you got your LWN subscription yet?
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 :-)
And that's what OOP should be - it should be abstracting away which modules to call and automatically parallelize the calculations on an array as optimally as possible for the platform. However OOP's fame has made it that programmers think everything should be an object within an object within an object.
Need an array? There's an object for that which includes the array and all functions you might ever need to call in your life as a programmer. Need a string? Here's an object for that where you can serialize it in a AJAX call and also divide your string by a numerical value. Need a low-level GPU calculation? Here's an object that instantiates the whole freakin' GPU's memory space. I just built a program - it's also an object so you can put your object in my object and we can object our programs together.
Custom electronics and digital signage for your business: www.evcircuits.com
Thinking in assembler is a last line of optimisation and not something that is relevant or even related to bloatware. Bloatware comes from recycling old APIs, writing new ones expanding functionality within the bounds of ensuring backwards compatibility isn't broken. Bloatware comes from being removed by several layers from the system. Sure I could write a hello world program on the command line in C, or I could write it in HTML5 to dump in the browser window, which causes more bloat?
I think in assembler, but then I write programs which are often limited to 16k of program space. The type of optimisation you get from "thinking in assembler" is like a for-loop using 7 processor instructions to determine its break condition, where as a while-loop uses 5. Compilers these days are fantastic and even in cases where space is a premium they are well documented so you know the for-loop is going to save you two operations on a while-loop.
I'd be more worried if they had never used a text editor.
> If by the time you get to university you don't have more than a basic (no pun intended) proficiency in programming then you're likely headed for a non-techie role.
I don't agree with this. Not everyone is from an environment where they will have been exposed to much of this stuff - certainly, before I went to university, I couldn't do any programming. I didn't know many people from any professional background really, just knew I quite enjoyed messing about with computers and figured I'd do computer science. My parents both work in the public sector, the school careers service was very heavy on public sector jobs (IIRC airline pilot was the only non public sector job which appeared on my list, and I'm colourblind which rules that one out...) In the end I've been a techie for 10 years now and am still mostly avoiding moving into management.
University is the first time people are really making their own choices on a large scale. Any assumptions made on a person before that are unlikely to be valid.
Copy, paste, compile, run, shudder.
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.
It was when I went through. Now, if Java is the new COBOL, how can it also be the new Pascal?
Did you every have any problems with pointers? The assembler courses are designed to make pointers understandable. I guess if you're working in modern languages that abstract away a lot of the memory management and so forth, you wouldn't need to know this. Then again, I still see buffer overrun holes announced in modern software built with all of the OO goodness money can buy.
Of course, TeX has been around since 1979 and is also "complete", so how hard can it be to maintain it?
At least the TeX User's Group doesn't take three years to implement a new version
Then they asked what I'd do if we were "forced to migrate to IIS." When I asked how this could arise, all they could come up with was "what if regulatory requirements force you to use Windows?" In other words, if we weren't willing to dump money into utterly unknown "future applications," we should really consider "standardizing" on Java because the government might mandate Windows.
Did they know that Apache and Perl are available for Microsoft Windows? Or were they worried that the government might mandate IIS?
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
I was going to raise the same point about optimizing compilers, but to your second point, I don't see a great deal of difference between "++i;" and "i++;" as far as clarity goes, and with operator overriding in (e.g.) C++, the actual work that goes on behind the scenes for the two flavors of "++" may well be more than any optimizing compiler can really cope with.
I strongly agree with the idea of striving for clarity and avoiding premature optimization, but when two approaches are equally clear, and one of them has a strong possibility of imposing pointless overhead, I see no reason not to avoid that approach.
The school you describe attending is not a Java/OO type school. I oversimplified speaking strictly about C. The point is that those schools using C or Pascal or a good chunk of other languages are teaching references and data structures and memory footprints and any number of things that are just unreachable and thus unteachable in the new Java/OO crowd.
You describe a rigorous program, far different from the typical program that stresses OO and begins students with Java as the base language for their CS career.
t
<sarcasm> I had the same problem with a database, we had some weird bug. So, me and a couple of programmmers wrote from scratch an entire DBMS with all the features of Oracle and without that bug. It took us a couple of days, though. Management told us not to slack so much next time.</sarcasm>
Yes, there are tradeoffs for using somebody's else work for your frameworks/libs/OS. Even paying does not protect you. And a bad choice of tools can be fatal.
But I bet that if that guy had gone to management and asked x men-months to improve/develope the tool by themselves, management would have say that it was too expensive and that there was no need to "reinvent the wheel" and that he had to "concentrate in the core bussiness" and "get external expertise" and use a product finished.
Ah, and from my experience whatever management says were the reasons for firing that guy and the real reason may have no relation at all.... management won't care if the project is impossible with the given constraints of technology/resources/time, if you try to explain to them they will resort to "I do not care about the technical details". But if they see the project coming behind their proyected schedule, they may find it useful to fire someone in order to show everyone that they "take care of things".
Why can't
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.
Good to know.
-- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
We're talking a person in their 20s that still, in 2003, sent out HAND WRITTEN job applications.
Sorry, I was thinking more of someone who didn't use a word processor to write programs.
Just one student?
I suppose in most cases this is true, but what crt0 does is very much platform dependent. I don't think of this as initializing the runtime "library" (although if your code calls stdlib routines it does do that as well) because what it is essentially doing is setting up the stack space, initializing the registers (possibly initializing the hardware); basically doing the housekeeping that an assembler program would have to do anyway on startup. In some embedded environments, crt0 is just a stub that does nothing because the ROM monitor establishes the runtime enviroment (stack pointers, hardware initialization, etc). In these cases (unless your C code does calls any runtime library routines, no runtime library code is included at all in the final executable. Most implementations of crt0 are actually inline code that is simply placed "in front" of the C "main" function so it doesn't really "call" the main function but either falls through to it or executes a jump to it.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
In that case the same would hold true for an assembler program. The OS has to interpret the shell command, load the program from disk, start up a process, initialize the registers, etc. before calling the entry point. In fact the only environment I can think of where your entry point would be the first thing executed would be if your code was in ROM and the entry point was set to the processor's reset vector (used to be 0xFFFFFFF0 on x86 - not sure if that still holds true with today's processors).
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
In general, your right, but this is not true in all cases. In some embedded environments the crt0 object module (the module that contains the _start entry point) is just a stub if the code does not call any library routines because the ROM monitor performs all initialization of the hardware, registers, etc.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
I could argue corner cases for just about any technique, including self-modifying code, but I wouldn't want to recommend that as a standard programming practice that all programmers should use.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
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/
In general, this is true. In most cases crt0 (containing the _start entry point) is placed before the main() function and performs the initialization you are referring to. However, while this is the default way, it not a requirement. Most C compilers include the source code to crt0 so that developers can write their own initialization code or none at all if not required. If your C code does not call any library routines, no other initialization may be needed (depending on the OS or embedded environment). In fact, it is usually possible (e.g. the -mno-crt0 switch for gcc) to tell the linker to not link the crt0 code and you can instead set the entry point directly to your C code entry point (doesn't necessarily even have to be main).
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
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.
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.
While it isn't around anymore, AmigaOS had a very object-oriented design. With the exception of the (BCPL-based) file system, AmigaOS was implemented in C and assembler, but the design of the O/S libraries and their interfaces was object-oriented back when C++ was struggling to escape from Bell Labs.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
I'm an ex-computer science major, so I may not be qualified to speak on this, but my experience in the field has asked me to offer the following input:
Computer science is not about how the machine works. In one sense, it's the last thing that computer science is concerned about. I'm not saying flat out that computer scientists don't or shouldn't understand the underlying machine, but there is always going to be a big grey area regarding how much needs to be understood and why. Knowing everything about the machine is a job for computer engineers, who are not "computer scientists." The difference is subtle and huge.
What does it take to write assembly? Most people couldn't reasonably write assembly code that fully takes advantage of modern chips and instruction sets. They're not even designed for human use in a "let me sit down and code something" sense. That may have been the case in days gone by, but nowadays knowing about machine code on the CPU level is less important for two reasons: one, that software available today relieves you of needing to know about it, and two, so much of what chips do now internally is obfuscated from the outside programming instructions that are issued to it further than ever before. In summary, assembly today tells you less about what the chip is actually doing, and it also is less relevant to the software that you need to write. I took one assembly course to satisfy my computer science major; we wrote code for a (now ancient) 16 bit virtualized microprocessor (the 8086); back then it made more sense to write assembly code for a regular programmer.
I think a computer science student could learn the appropriate lessons that assembly code used to teach by programming Java bytecode or some other virtual machine. This is a good example because there is no actual "machine" there to learn about, but you're still learning "how programs work" like you said.
My favorite computer science quote is that "Computer science is no more about computers than astronomy is about telescopes." If you ponder over this, you will be enlightened.
So in summary, no, I don't think computer scientists should start in assembler. I think computer engineers should learn programming that way. Computer scientists are best served by starting in a functional language, preferably a pure one. My first language in computer science was an OOP language: C++ (which isn't even very good for OOP). It really was a mistake to start with this language, and it didn't help me to learn more about computer science. I later learned Java, but that too was not good enough. Eventually I started picking up Lisp, but by then it was too late--I had already changed majors. :)
Yes, when I first was learning, pointers were a somewhat hard concept. I'm not sure you need assembly for that though; some basic education on computer architecture should suffice, and the rest really, semantically speaking, is a matter of having "indirection variables"... variables that know where to find some other value.
I want to play Free Market with a drowning Libertarian.
It depends on what they are trying to achieve. I've often thought university CS really ought have two streams, science and engineering , so the student can chose whether he's doing it for employment or if he wants to be involved in CS research. (For contrast think of the difference between a physicist and an engineer. An engineer APPLIES physics, a physicist DISCOVERS physics)
OO is brilliantly productive technology, it encourages people to think in terms of modelling and interactions, and it naturally suits the UML style of project design and management. If I'm hiring coders for a real work task, they better damn well know OO, not just as pseudo namespaces for structured programming but how to think in objects, models and stuff, because we'd be doing a heck of a lot of that.
However from a computer *science* research point of view, OO really isn't the most interesting game in town, and I think CS has been starting to look back at the functional and non imperative modes of coding as a better foundation for really understanding algorithms. Once thats well understood, students can then learn OO/structured/etc with a much deeper understanding of WHY a good algorithm works, not just how to do it.
This is especially important as the age of parallelism is starting to show up OOs short falls. I'm still regularly surprised at the amount of coders , for instance, that don't know why "side effect" programming is bad, or if they do, don't know why.
Don't get me wrong, OO is still vital technology and is still the centerpiece of my personal toolkit of coding skills, but science vs engineering are different practices and whilst OO is great engineering, its not that interesting anymore as science.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
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.
My thoughts exactly. Who cares what they teach in 111, there are other classes that teach difference nuances of programming (15-412 and 15-451 were a couple of my favorites). Now if they announced that they weren't teaching OO to *any* students, I'd have to start scratching my head....
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
Of course abstraction and code reuse came before OO, but OO makes it much clear and easier to learn and understand pre-existing code, in my opinion. I can code in Java, C++, and Scheme, and I can easily say that code writtn in Java or OO C++ is much easier to figure out (with or without documentation) than Scheme.
Well, you're also injecting an argument about compiled vs. interpreted code, too, which has its own pros and cons. I would agree that you can write the same program to run faster in assembly, but the time lost far outweighs the time gained in execution. Remember that nowadays programmer time is expensive and computer time is cheap.
If a CS graduate does not understand the difference between passing by value and passing by reference, there are serious problem with the way that CS curriculum is designed. My college's CS program is not one of the best ones in the country (USA), but we started out with C++ to understand what programs are, how the interact with the OS, things like that. In that same intro course, we touched on OO (in C++) and assembly, but mainly as different ways to code rather than different ways to think of a program. Follow on classes got into the theory of OO and what assembly code (which is basically shorthand binary) does in the processor itself. Whether they're better for practical programming or not, all of these things should be covered in undergrad CS.
As for crappy code, any profession runs into this dilemma. The modern tools we use (chainsaws, prewritten code, power tools, etc) are all very effective and efficient because of the history of professionals who have refined them. Would you think any less of your car mechanic if he didn't know how his tools worked, but could still use them to fix your car? Does that matter to you, the one who contracts his service?
Yes, we know that in embedded environments, things are different. Thanks for repeating yourself five times. However, on the big 3 OSes, and certainly many more, there is a whole lot of user-space activity that takes place before getting to main(). On standard glibc Linux, for example, after the fork completes, the real entry point is in ld.so, which loads dynamic libraries, calls any constructors, initializes stdio, initializes malloc, initializes threads, etc. Finally, the standard stack is setup before calling main(). Yes, with the right arguments to gcc, you can skip all that stuff. The point is, however, for most non-embedded software, your program, even if it's a simple C program, is actually embedded within a framework (glibc on Linux, Win32 on Windows, etc.) and main() is not the entry point for your program.
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.
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.
A framework is a collection of libraries and other resources, like daemons and agents. The C runtime (including crt0.s etc) can be said to be a framework. In fact, "runtime" is closer than "library". You could say, for instance, that the is a Core "runtime", a UI gadget "runtime", a Windowing "runtime", a "video rendering" runtime, etc - but it's a bit weird conceptually to have multiple runtimes. Enter the term Framework. In older days we used to call these "layers" and similar, but Framework is more general and doesn't paint you in a corner where you're forced into layering violations just to get something to work. A Framework may also include daemons, like a UI manager, SNMP agent, or such.
Also...
I would rather rescue the drowning Libertarian, not play insensitive games as if her life were of no value.
However, to cut to the chase, even though there is no "universal" definition, IMO the commenter that posted the response that started this, something akin to "you call a library, a framework calls you" basically had it right, although as often happens on /., it got completely picked apart. I wouldn't consider (nor would any knowledgeable C programmer I know) the C standard library a framework, regardless of how many machine instructions are executed prior to beginning execution of your logic. That has nothing to do with it anyway. A framework attempts to enforce a predefined way of doing things. In many cases, applications that are invoked via a framework really become extensions or features of that framework, but the core logic is driven by the framework. A library on the other hand is simply a collection of routines that can be called by your applications. What goes on at the machine level really has very little to do with the distinction.
By your description of what constitutes a framework, every single program, regardless of whether it's C, assembler or brainf&ck, is part of a framework because one or more machine instructions gets executed before your main() entry point. I guess we should alert the standards committee that the name needs to be changed to the "C standard framework".
My point is, no program just pops out of nowhere on your machine and begins running. There is always some set of instructions that get executed to prepare for your program to run. However, main() is, and always has been the entry point for a normal "C" program. How this entry point gets invoked is irrelevant (or at least "should" be for the sake of portability). To argue otherwise is purely pedantic.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
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.
You are missing the forest for the trees. It's not just about a few extra instructions in front of main(). Yes, technically there are a "few" extra instructions in front of main(). But the reality is that there is actually an entire framework defined by both the OS (kernel and userspace) and the C runtime that calls into main() and also manages other aspects of the operation of your program. I don't think the argument that "by your description, every single program...is part of a framework" is valid. For one, the argument does not rest on the fact that there are a few instructions before main() (see above) and secondly, if it turns out that every single program is running as part of a framework, then so be it. After all, every single program we have today, whether written in C, assembly or brainfuck does, in fact, run on a computer. Is that a problem? No. That's just the reality of things. These days, we have powerful and rich environments and programs simply fit into those environments. Some environments (platforms) are smaller and less intrusive than others, I'll grant that. But at the end of the day, there is always a framework and it generally does a great deal of work. That's where we are. Deal with it. Either that, or go program on embedded where you don't have a runtime environment, per se. And I'm not knocking that either. Just stating facts.
There have been OSs for the last 50 or so years and there have been libraries for a great many years as well. Frameworks are much more recent and generally include certain features such as default behavior, IOC, extensibility, etc. In a typical non-framework application, when your program receives control via main(), the entire remaining logic flow is pretty much up to you. This is not so within a framework. In the first place, most frameworks (at least the ones I've used) don't call main(). Instead the framework invokes a function within your C code, usually via callbacks and expect your code to return certain values (and sometimes within certain time constraints). Generally, your application consists of callback routines which are invoked by the framework. This is very different from a standard C program which begins at main().
You are entitled to your own opinions of course, but not your own facts. While there are certainly many grey areas between what may be considered a library and what may be considered a framework, and there are many libraries that may call themselves frameworks when in fact they are libraries, frameworks are not the same thing as libraries and OSs are certainly not frameworks. QT is a framework, the linux kernel is not.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
Concrete example of state mutation? Methods.
Compared to one that knows how his tools work? Yes. All right, both can call themselves mechanics. Or what about "repair man" vs. "Mr. mechanic" ?
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.....
Turing completeness is an abstraction that, while useful in the Itower is less useful out where users can type just about anything, at anytime, with any intent, and then produce just about any complaint in response to any response the software might make.
I'm not sure I understand how this is relevant; what I was saying is intended to be abstract. All languages once in a certain class (which, according ot that one guy in some other post, I am not allowed to mention so that I don't sound arrogant) are equivalent, so at least going down to asm does not give us any more theoretical power. Therefore, we're free to choose a representation, and my position says that for the human mind, asm is a remarkably bad representation for a symbolic expression in that class of languages, and coding in it does not produce as much insight about programming in general as some people try to claim. I am a bit of a believer in the Sapir-Worf hypothesis as far as programming languages go -- programming languages shape thinking processes about problems. And I never have had a symbolic thinking process about a problem that represents asm a bit.
This is not a problem if the software is trivial, but if the software is non-trivial than it becomes a much more difficult problem. Turing completeness is such a simple thing it cannot capture real-world complexity in software use.
As far as I agree with it -- I sort of do, but it's not a Turing-completeness issue -- it seems like my preference for higher-level languages would indeed manage complexity in non-trivial software better, no?
Also...
I would rather rescue the drowning Libertarian, not play insensitive games as if her life were of no value.
Well, that exercise is outright designed to find the fair value of his life... I suspect that to both of us, the value is actually quite high indeed, and we'd come to an agreement about that.
I want to play Free Market with a drowning Libertarian.
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.
Well, code readability and maintainability often mean a good design, which means that the problem is understood correctly and that the program can be seen to be correct. These are very good qualities in a language if it helps in achieving this.
Productivity is just a side-effect of a good language; for me this issue is more philosophical than that. The actual conceptual features of higher-level languages outright produce better thinking about issues...
I want to play Free Market with a drowning Libertarian.
Well that sounds like nonsense then, I thought the argument was deeper. In fact the opposite is true: holding state in multiple independent objects tends to make an algorithm more parallelizable, not less, provided synchronization does not require serializing access between objects.
Have you got your LWN subscription yet?
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.