Weekly Edition
Return to the Development page
| |||||||||||||
|
| |||||||||||||
Quote of the week
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. 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.
-- Carnegie
Mellon University professor Robert Harper(Log in to post comments)
Quote of the week Posted Mar 24, 2011 3:02 UTC (Thu) by sciurus (subscriber, #58832) [Link] The report on their new curriculum is an interesting read. Non-majors who want to take a single CS course will take one the emphasizes "computational thinking" and uses a scripting language (likely Python). CS majors will have to take classes in imperative (a subset of C) and functional (Standard ML) programming before taking the data structures and algorithms course. Non-majors who want to take multiple CS courses (e.g. engineers) can just take just the imperative programming course as their prerequisite for upper-level courses.
Quote of the week Posted Mar 24, 2011 17:29 UTC (Thu) by pflugstad (subscriber, #224) [Link]
I find it odd that they consider OO to be non-modular. Modularity is kind of the point of OO IMO.
Quote of the week Posted Mar 24, 2011 22:08 UTC (Thu) by rwmj (guest, #5474) [Link]
OO is bad at modularity. Code is split over many objects ("nouns"), meaning you have to chase the flow of control over many classes, and in some languages that means across many files. Plus you may not know until run time whether some object overrides methods in another class, making it very hard indeed to follow the flow. Of course IDEs help in this respect, but that's just admitting that the code is hard to understand without needing a very heavyweight, slow and intrusive tool to help you.
Functional programming (in broad terms) separates data structures from code that operates on those structures. The code is in one place and follows a simple flow of control -- for example if a function is called, it's clear at compile time which function is being called.
I'm speaking from experience here. It took me a long time when learning ML and OCaml to unlearn bad OO habits, but I now consider myself a much better programmer as a result, and tend to pity people still stuck in OO paradigms (except in some very narrow cases where the OO paradigm works).
Rich.
Quote of the week Posted Mar 25, 2011 13:48 UTC (Fri) by scripter (subscriber, #2654) [Link]
For an introductory course in programming, I think it's wise to eliminate object oriented concepts from the dizzying array of concepts that students must learn.
As I reflect on my journey of learning to program, I started with TI 99 BASIC, PET BASIC, and GW BASIC. I transitioned to Pascal, then C. No object oriented concepts there. OO languages came later, as did Scheme.
----
Regarding professional programming, my perception is that the programming language matters far less than the tools, the instrumenting, the libraries and the people writing the code, and their ability to solve real world problems.
Quote of the week Posted Mar 26, 2011 18:23 UTC (Sat) by Tobu (subscriber, #24111) [Link] It's amusing to see this next to the Django 1.3 release announcement, which introduces class-based views. The Pylons lead developer has argued that exposing the Pylons classes to inheritance exposed too much of the implementation, and prevented him from making some necessary evolutions to the framework. It's a big reason Pylons 1.0's successor, Pyramid, is mostly based on repoze.bfg (with zope-style components under the hood).
Quote of the week Posted Mar 26, 2011 22:33 UTC (Sat) by maney (subscriber, #12630) [Link]
Actually, I think Django's class-based views are a *great* example of the kind of "stuff is smeared all over dozens of classes/files" problem. I speak as one who, a couple weeks ago, sat down and puzzled out how those couple dozen classes get composed into the actual view classes (and I skipped the whole raft of date/time based stuff, as it wasn't relevant for me). Much head scratching, partial sketches, a wonderfully messy page full of class-representing blobs with snakey lines (different colors help) all over... I finally broke down and, rather than redraw it on a larger sheet of paper, used dia's UML boxes to make a readable version. Of course I found some things I'd gotten wrong, and then some more, and one trivial code duplication (bug filed with patch; was applied a few hours later).
And I still haven't migrated any of the views in the application I'm working on, which was the original motivation for all that. Sometimes that sort of thing makes you see your own code in a new light, and I've been doing a lot of refactoring, cleaning it up. And while that has seen one group of tightly-interacting functions get turned into class methods, none of the actual views have, and I'm starting to wonder if doing so is even a good idea. Asking myself that question, OTOH, has already been good for the codebase.
|
|
||||||||||||