Slashdot Mirror

UML is used only for notation and documentation

Actually, you're wrong there. It's a floorwax AND a dessert topping.

As Martin Fowler states in UML Distilled:

"In fact, the UML is a few different things to different people. This comes both from its own history and from the diffrent views that people have about what makes an effective software engineering process."

UML can be a programming language in and of itself, where all the code for some application is UML, or it can also be merely used for varrying degrees of documentation.

Both he and Steve Mellor independently came up with three modes in which most people use the UML:

• Sketch
• Blueprint
• Programming Language

Sounds like you're familiar with the first two, but the latter does exist as one of the primary three modes.

UML, like most other other software engineering fads exist mostly because groups like OMG want to push new consulting fees to large commercial companies, publish more series of books and create forums for them to lecture to (and charge fees).

On this, I'd also would have to say you're probably a bit off. The UML exists mainly because there was a Tower of Babel of somewhat similar approaches to the same problems being invented and used all over the place. At least the UML did manage to unify that mess. Of course, the consultants would be makining money regardless, however my personal feeling is probably that the multiple pre-UML solutions would have offered them even more fertile ground to exploit.

GML is the only proper tool for these kinds of jobs. It's been through the fire of real projects, streamlined and factored to the essence of the task, and gives these diagrams the legitimacy that they really deserve in the design process.

Big fan of GML.

Purdue had one. I believe a girl did sue, actually. Although, I have to give her some credit; the brakes were faulty and she got hit by a bus. link

Okay, okay. So SHE hit the bus. Semantics I tell ya. The program was killed due to widespread vandalism.

Portland, Oregon had (and could perhaps still has) one; the Yellow Bike program. Google says they still have it: link

"I'm not really a PERL developer."

Obviously not. You think Perl is an acronym.

BTW, even as a novice Perl developer, I can confirm that repeated use of <> and $_ will add several cm to your manhood.

Agree with heroic Hertzfeld (more info in Programmers at Work ). I'd add Warnock and also strongly endorse Wolfram (whose invincible iconoclasm is admirable). And PARC should be better represented, I'd cite Adele Goldberg for the under-appreciated Smalltalk-80. At least she gets to contribute to Cringely's Triumph of the Nerds.

Where are Dijkstra and Wirth (who did far more than most people realise - Wirth essentially created a European "Sun Microsystems" at ETH)? Remove the "+10:American" bias - but Knuth should probably be mentioned at least twice. :)

Hm, interesting. I don't know about you, but spending my time coding around typing issues, which can be better handled automatically using duck typing, is exactly my idea of "huge cost".

You are nitpicking and poorly. In order to discuss homosexuality or breast cancer you don't need to show sex or simulated sex. Nor do you need to describe it in explicit detail. Somewhere there is a reasonable compromise where we can have politically valid discussion of issues and still not have to worry about our kids listening to radio and hearing a couple having sex live on some radio show. (And yes that has been aired)

The OP was speaking about a small group filing thousands of complaints and saying in an alarmist fashion that they were censoring us. What exactally has been censored? That is the question I ask and will continue to ask.

IT knowledge is a perfect adjunct to the real skills that get you a job. That's the same as ever.

I have found that employers seem to give little value to domain (industry-specific) knowledge. Here is a c2 discussion about that.

..Christopher Alexanders work with, "The Production of Houses" and, "The Timeless Way of Building".

Check it out Christopher Alexander

"Heisenbug as originally defined--and I was there when it happened--are bugs in which clearly the behavior of the system is incorrect, and when you try to look to see why it's incorrect, the problem goes away.

This is a really cool article, but it was especially fun to see the heisenbug mention. Years ago, some fellow CS people and myself conjectured a similar phenomenon that seemed to manifest once in a while, in which a computer malfunction goes away after one "proves" that there's no cause for the error to exist.

Here's a list of heisenbug anecdotes, but note that some of these submissions aren't strictly heisenbugs.

Oh yes the answer to your question is, based on my informal survey of "In Soviet Russia" jokes here and at http://c2.com/cgi/wiki?InSovietRussia, the object can either be YOU or the subject of the sentence (if that was not "you").

"In SR, old robots talk to YOU!"
"In SR, robots talk to/about old people"
"In SR, the children think of somebody"
"In SR, the children think of YOU!"
etc.

The answer is, as always, to take a holistic view. Graduates with no experience often have just enough knowledge to make them dangerous and belligerent. Long-time developers with no formal training sometimes end up egotistical, inflexible, and lacking the skills necessary to move from a development mindset to an engineering mindset. What you need is a degreed professional with experience.

And you may want to read goto considered harmful; you'll find out that, in many cases, it's not.

(Not rhetorical... I'm really asking.)

cmath.sqrt((reduce(operator.add, [i**2 for i in l], 0)-(reduce(operator.add, l, 0)*reduce(operator.add, l, 0)/len(l)))/(len(l)-1))

Actually, the parent doesn't seem to have a clue about the true origins of "In Soviet Russia..." stuff. The originator of these was Yakov Smirnoff, more information than anyone should care about (as well as a collection of "In Soviet Russia" jokes, the vast majority of which suck) can be found here.

Please re-read some Niven. The gripping hand is not a kewler way to say "on the other hand". If you check into the origin of the phrase, it is used for a third alternative - on one hand, on the other hand, and on the gripping hand.

ML!?!!! But that's yet another functional language I don't know!

Sigh... you may or may not have been joking here, but I want to make it clear that I said ML instead of OCaml is because it's common across the ML family of languages, just as some concept may be common to *nix or *TeX.

Yes, of course it makes sense, and no thanks for the slur on my education

Hey, you're the one who said you only had a minimal introduction to recursion. And since you said that the horrific example of recursion you gave came straight from that introduction, I'd have to surmise that it was a very poor introduction. You've certainly given me no evidence to the contrary... Especially when you say things like:

So far, you've had to resort to special FP specific tricks like "memoization" and "tail-recursion" in order to try to match normal imperative programming results.

Memoization and tail recursion are hardly FP specific.

I'm not sure I'm interpeting your example correctly, but this is what I think it does, and the minimal mental operations required to process it:

Close-ish, but not quite right. It's more like:

(1) Define a function map that takes f and lst as parameters
(2) Define a function map_helper, local to map that takes three parameters, f, lst, and acc. This function does the following:
(3) Pattern match on lst. If lstis an empty list
(4) Reverse acc
(5) Return it
(6) Otherwise split lst into its first element and a list of the remaining elemets, call these head and tail.
(7) Apply f to head
(8) Cons the result onto acc.
(9) Overwrite the current stack frame with a new one where f is the same as it was before, lst is replaced with tail, and acc is replaced with the value computed in (8) -- Goto (3)
(10) Call the function defined in (2) passing it f as f, lst as lst and an empty list as acc.
(11) Return whatever value this hands back to you.

Note that there is no stack growth (well, there is one new frame appended for the first call to map_helper [I think... the compiler may optimize this call away as a tail call as well -- I'll have to see if that's the case]), and then for every additional call to map_helper, the current stack frame is just reused. And so we have the following concepts to handle: Define a function, apply a function, add and remove elements to/from the head of a list, return a value. That's all...

Of course there are a few neat things that go on under the hood here. For example, the compiler is able to determine the following things about map:
map_helper's f must be a function that takes something of unknown type 'a and return a value of unknown type 'b ('a -> 'b). It knows this because we apply it to head in step (7).
map_helper's lst must have type ('a list). It knows this because f (of type 'a -> 'b) is applied to head in step (7), so head must be of type 'a, and the list it came from must be an 'a list (as OCaml lists are homogeneous).
acc must have type 'b list, because we stick (f head) in it, and f returns values of type 'b.
map_helper is a function of type (('a -> 'b) -> 'a list -> 'b list -> 'b list) because it takes f, lst, and acc of the first three types and returns the reversed acc, which has the same type as acc
map's f and lst are of type ('a -> 'b) and 'a list respectively, because that's what it passes into map_helper's f and lst, and it

Have a look here:

http://c2.com/cgi/wiki?ProjectManagement

they never adapt the lexical model of LISP

Ever heard of something called XML?

As Tim Bray points out, "XML does a lousy job of what Lisp S-expressions could do decades ago."

Value judgements aside, we can at least all agree that it's trivial to interconvert lexically between a LISP expression and an XML expression.

Further discussion on the C2 Wiki.

Many of the newer code generation tools are very flexible and have some ability to preserve changes to the code; making them easier to fit into real development cycles.

The way I look at it, there's only one good kind of code generator: the kind whose output I almost never look at and never, ever tweak. Compilers, for example, are a kind of code generator that I love.

The other kind of code generator strikes me as just half implemented. Somebody has come up with some sort of interesting abstraction, but they haven't pushed it as far as a service, library, or compiler that you can use happily. These days I never use them.

What's the difference? Maintenance cost. A code generator produces a lot of code that is, pretty much by definition uninteresting. That means that you've hidden the actual interesting code in a whole mess of boring code, which makes it really expensive to maintain. And generally the generated code is highly duplicative, meaning if you want to change certain things, you have to change them in a lot of places.

To me, it seems like code generators dramatically worsen the cost-of-change curve. For any project where you aren't already planning to throw out the code, this strikes me as a mistake.

Here's my set of software predictions. Some more detail to fill in for that other guy's blog entry.

Here we go:

• Refactoring Browsers - let you change the name of a class, method, whatever- and have perfect replacement across the project. This is important, because it means that our API's can feature consistent naming schemes, without a whole lot of upfront planning. These exist today, but not in common use.
• Spatial Code Browsering - The ability to organize our textual code in a shared diagram, so that we can arrange it the way that we think of it. Most of our code is text, for various reasons. But we tend to think of spatial relationships between blocks of code. There's no reason why we can't lay out the files spatially, share those spatial layouts, and browse those spatial layouts.
• Replay Debugging - You can make programs run in a virtual machine that tracks deltas over time, or keeps time slices. You can "rewind" or "fast forward" a test execution, introspecting into the state of variables at different points of time. If your debugger is smart enough, it can answer the question: "now how did THAT come to happen?" "Why did you do X? Why didn't you do Y?"
• Publish-Subscribe - Is it just me, or is publish-subscribing becoming more important? That's because we're going to component systems.
• Tuple Space(s). By my limited understanding, this is a model of programming where you have: A gigantic data store, and little micro-programs that pull and push data to the store. For example: Let's say you have a web-app. The web server receives a request, and pushes it into the store, in the form of a graph. So, for instance, you get the "request" node, and it links up to a node representing the time it was received, and it links up to the URL, and it links up to the response to be filled out, etc., etc.,. Then if a program knows how to fill out the response, it starts filling out the response as much as it can. For things that aren't at it's level of abstraction, it leaves for other programs. When things are fleshed out enough for those programs, they automatically jump into play, and fill out the rest. When it's all fleshed out, the web server recognizes that the "done" flag's set, takes the whole thing, ships it out, and then clears everything. What's new here is that what triggers programs/procedures is the state of the tuple store, the shared graph- programs register states that they can metabolize, and then when conditions are right, the programs are invoked. Your programs are collections of traps. Mixes declarative programming with imperative programming, in step with development of the semantic web.
• Non-boxy interface, Deep visualization - Our GUI tools are all "boxy," and there haven't been any real UI advances since MFC, and I do blame the API. It's easy to imagine API's that allow you to specify call-outs, how icons that contain icons are specified, the ability to compose and connect icons, etc., etc.,. But we're still in the images, rectangles, buttons, and tree views days, as far as easy-to-use API's are concerned. As SVG matures, I believe that our API's will get less rectangular, and give us visual and interactive power on the cheap.
• Social Help Documentation - I think we'll see integrated help documentation linking up with things like wiki and programmer's forums. So you'll be able to read a function's documentation, and see 17 examples of real use of the function and commentary. It won't be a seperate open-a-web-browser and search thing, it'll be easily available and connected with the deployed documentatio

Here's my set of software predictions. Some more detail to fill in for that other guy's blog entry.

Here we go:

• Refactoring Browsers - let you change the name of a class, method, whatever- and have perfect replacement across the project. This is important, because it means that our API's can feature consistent naming schemes, without a whole lot of upfront planning. These exist today, but not in common use.
• Spatial Code Browsering - The ability to organize our textual code in a shared diagram, so that we can arrange it the way that we think of it. Most of our code is text, for various reasons. But we tend to think of spatial relationships between blocks of code. There's no reason why we can't lay out the files spatially, share those spatial layouts, and browse those spatial layouts.
• Replay Debugging - You can make programs run in a virtual machine that tracks deltas over time, or keeps time slices. You can "rewind" or "fast forward" a test execution, introspecting into the state of variables at different points of time. If your debugger is smart enough, it can answer the question: "now how did THAT come to happen?" "Why did you do X? Why didn't you do Y?"
• Publish-Subscribe - Is it just me, or is publish-subscribing becoming more important? That's because we're going to component systems.
• Tuple Space(s). By my limited understanding, this is a model of programming where you have: A gigantic data store, and little micro-programs that pull and push data to the store. For example: Let's say you have a web-app. The web server receives a request, and pushes it into the store, in the form of a graph. So, for instance, you get the "request" node, and it links up to a node representing the time it was received, and it links up to the URL, and it links up to the response to be filled out, etc., etc.,. Then if a program knows how to fill out the response, it starts filling out the response as much as it can. For things that aren't at it's level of abstraction, it leaves for other programs. When things are fleshed out enough for those programs, they automatically jump into play, and fill out the rest. When it's all fleshed out, the web server recognizes that the "done" flag's set, takes the whole thing, ships it out, and then clears everything. What's new here is that what triggers programs/procedures is the state of the tuple store, the shared graph- programs register states that they can metabolize, and then when conditions are right, the programs are invoked. Your programs are collections of traps. Mixes declarative programming with imperative programming, in step with development of the semantic web.
• Non-boxy interface, Deep visualization - Our GUI tools are all "boxy," and there haven't been any real UI advances since MFC, and I do blame the API. It's easy to imagine API's that allow you to specify call-outs, how icons that contain icons are specified, the ability to compose and connect icons, etc., etc.,. But we're still in the images, rectangles, buttons, and tree views days, as far as easy-to-use API's are concerned. As SVG matures, I believe that our API's will get less rectangular, and give us visual and interactive power on the cheap.
• Social Help Documentation - I think we'll see integrated help documentation linking up with things like wiki and programmer's forums. So you'll be able to read a function's documentation, and see 17 examples of real use of the function and commentary. It won't be a seperate open-a-web-browser and search thing, it'll be easily available and connected with the deployed documentatio

• they be a professional product manager
• that they fairly represent the needs of all stakeholders
• that you have weekly demos of progress that all stakeholders are invited to attend
• that you release early and often (weekly if you can, but no less often than quarterly)

Sometimes data flow is necessary such as in the example you give. However, that does not mean that the only way to solve such a problem is a procedural solution. There are object oriented solutions to such a problem as well.
The key concept is encapsulation. If you expose your attribute (price) to the whole world, then an unlimited number of clients can couple themselves to this, creating brittle code. So use a Builder pattern . Define an interface for exporting information about your Item object. For something like a Cart, define an interface for importing information (building) a Cart. Create a concrete class(es) that implements these interfaces.
Notice that I'm not writing code here, I am designing. To most programmers (myself included!) that kind of statement seems pompous, but there really is a big difference in these two difficult tasks. This may also seem like too much work, too difficult, etc. It is definitely not the easiest/quickest way to solve the immediate problem. That's not the point of object oriented programming. The point is that it makes for code that is more robust and easier to maintain.

Seems they're looking to reinvent COBOL, and we all know what a great success that was. Anyone remember The Last One ??

They'd do better actually talking to lingusts and looking to apply the principles of natural languages to programming, rather than the syntax.

Of course, some people have discussed this already, but you say things like Local ambiguity is okay or Topicalization or Pronominalization to a lot of developers and they can't see past their prejudice of "I know one language and I'm too scared to look at another".

If you dare let go of your prejudices and re-consider some of the fundamentals you might just be surprised.

BTW - I'm currently learning morse code and I encourage you to learn it too. Here is quite good program that will teach you - http://c2.com/morse/

Actually, I for one tried to learn perl once.

I tried to absorb the syntax docs one afternoon, but it gave me nightmares. Literally. It was as if the C-programming-part of my brain was in conflict with the oddball operators and constructs presented in the perl language. Ever since I've been haunted by perverse unreadbility of it all. I liken the experence to attempting to think in brainfuck.

So by this I know for a fact that perl is Not My Thing(tm).

Now, a more objective reason as to why perl isn't generally a good language (but not completely bad) is evident in the very syntax of perl itself.

Useful code shouldn't be as inscrutable as its compiled counterpart since that defeats the whole point. Perl is a language, so it follows that it is a communication medium. By that it should be able to communicate something to a party outside just the author and the perl interpreter. It can accomplish this, but not without the reader having to go through the mental gyrations of what could be best called linguistic decompression. The language has this tendency to impose this extra step to yield the information communicated. Simply put: it gets in its own way.

Now, useful programs on the other hand follow a different set of criteria of course. I've used perl-coded stuff online all the time, and enjoy its reliability and speed.

I'll give credit to the fact that perl is compact, terse, to the point and has a reputation for string manipulation. It fills this niche rather well, and is a prime example of the being "the right tool for the right job".

IMO, "the right job" for perl is about 2% of all programming tasks out there. This is evident by the fact that even though perl was the prominent CGI language of the mid-nineties, it lost the overwhelming majority of that interest with alarming speed.

As for python, I'm sure it fills a niche too... whatever the hell it is.

Er, PHP stands for 'PHP: Hypertext Preproccessor' (gogo recursive acronyms!), not Personal Home Page.

IMHO the Wiki concept is a revolution that's not comparable to any other development since the invention of the Web itself by Sir Lee... Think of Wikipedia or the original c2.com wiki, both examples of the success of this idea. These sites are driven by the users themselves, and are able to gather astonishing amounts of high quality information.

The beautiful thing about Wikis is that they scale to any size. I use Wiki for personal information management. My company uses Wiki as a kind of rapid CMS (which effectively replaced Lotus Notes in that function btw), as do the big sites I've mentioned with millions of users.

Some custom extensions can turn Wiki into tech unbeatable by any commercial product - because the concept just works (tm)...

"Never attribute to malice that which is adequately explained by stupidity."

Hanlon's Razor

His point is that Perl shouldn't be in all caps. It's not an acronym. See http://www.perl.org/about/style-guide.html or http://c2.com/cgi/wiki?PerlIsNotAnAcronym.

Why am I doing it that way? Because its the one benefit exception people claim it gives them. If you catch after each line it is exactly like error codes. OF course its error codes with wird syntax and passing methods, so why not just use error codes?

Wow. What a strange response.

I don't know where you got the idea that "exception people" claim it's a benefit that you can use exceptions in a way that's just as painful/limited as code using a return-error-code style (though even if you do that, they're still not exactly alike - the exception-throwing style still has advantages).

The major advantage of using exceptions (in my mind, at least) is that there is no need to use special return codes to signal errors. And there is no way to ignore an exception (as a coder can easily just not check a return code). And you can handle an exception at the most appropriate point in the call stack. And your code doesn't have to have a maze of return-code-checking logic after every single bloody might-possibly-return-an-error function call. And you can signal a failure even from a function that doesn't/can't return a value (eg. a constructor). And an exception object can carry arbitrary information along with it. And cute furry animals and small children will trust you. Your gender-of-preference will find you more attractive. You'll need less sleep and earn more money. Colours will seem brighter and the air fresher. Your google searches will work better.

The candidate you support will still lose the election, but hey, you can't expect everything :-).

Slightly more seriously, I think you might be suffering from a mild form of the Blub Paradox WRT exceptions (specifically C++ exceptions in this context). You may find it's worth taking another look, because you are missing a lot if you think of exceptions as just a syntactically weird equivalent of return codes.

Microsoft really made me believe that wmv9 was mature enough to be an industry standard.

Excuse me, but it's a company's job to make people believe their stuff is good and the best and is what you need, what everyone needs. This has been the main MS policy since the beginnings, to make people believe and accept that what they need is right there in their hands.

But over time some people evolved technically to the point where they can see that just because some fscking rich guy says that things are supposed to happen the one way they wish, that shouldn't be and isn't always true.

Regarding WMV9 vs H.264/MPEG4-AVC... there shouldn't have ever been a debate about this. Even basic H.264 implementations show enough that one could see it is a good solution. WMV9 is nothing more that MS gathered while being around all comitee meetings regarding the evolution and implementation of H.264 features. Trash together a working implementation, add a few million bucks on marketing and brainwashing, pay some dinners for the right ceo's and hey, what you get ? WMV9 on HD DVD's. Nothing new here, just how things work.

Too bad that there are some people who know some stuff about technical matters on HD video coding and some of them work around SMPTE and not at One Microsoft Way.

For those not in the know, in (afaik) every episode the person who wore the red shirt died. See a wiki on "red shirt".

I saw something about this on TV, I think on a Frontline about video games. There were these larger-than-life screens - (3) two-meter square arranged dressing-room mirror style - that each soldier in training interacted with. It used voice recognition, and AI (no expanation as to what kind of AI). In the episode, the man's task was to move a woman and her wounded daughter off the road so that road could be used for transport. Also, there would be some danger to the woman if she stayed.

Wargames have been used in the military for centuries. Chess is a great and well known simulation designed to improve your critical thinking skills. Recently it's been proven by Gary Klein in his excellent book Sources of Power training shouldn't be academic. I think we'd all agree that it's one thing to read about, say, being a firefighter, and quite another to run in to a burning building and make decisions that affect dozens or hundreds of lives. Simulations are designed to train your mind to become accustomed to these situations, and are probably the single most effective tool in doing so.

What I want to know is how long before one of the cadets in training hacks the computer to turn the odds in his favor.

yeah but everyone should at least understand the concept of "type" a strong typed language should be used

Python is a strongly typed language. More strongly typed than C in fact. People often think that Python is weakly typed because variables do not have a particular type associated with them. However, in Python it is the values that have types. Python variables are just names that make it convenient to manipulate those values.

Python is strongly dynamically typed, like Lisp and Smalltalk. Other combinations of strong vs weak and static vs dynamic are shown here.

TTFN

Yeah, sure it is turing complete. It also has a self -hosted interpreter, that's of course always a sign of a rather mature language.
You seem to be stuck in the Turing Trap. That can easily lead to another verification of Greenspuns 10th Rule of Programming. Try to find out how to beat the averages, please.

Yeah, sure it is turing complete. It also has a self -hosted interpreter, that's of course always a sign of a rather mature language.
You seem to be stuck in the Turing Trap. That can easily lead to another verification of Greenspuns 10th Rule of Programming. Try to find out how to beat the averages, please.

> Ruby is a better fit for this problem?

There's a good C2 Wiki page on this - PythonVsRuby.

Kudos to Jean-Marie Hullot, who contributed to this by designing "Interface Builder" !

Kudos to Jean-Marie Hullot, who contributed to this by designing "Interface Builder" !

Anyone remember "The Last One," which was supposed to make all programmers obsolete?

You don't? Wonder why? :-)

http://c2.com/cgi/wiki?TheLastOne

-Urocyon
(Too lazy to create an account.)

can we be a bit more dismissive and insulting?

Sorry, just having a bad week. I apologize.

abatave shielding, cince you do not understand what he is talking about...

I know what ablative shielding is. Every space capsule used it. Tanks use it. I mentioned DS9 since the terms, "ablative armor" and "micrometeoroids," are common in Trek.

if the space ship can not take machine gun fire at it without damage, then it has no chance in interplanetary travel where you have to cross an asteroid belt

Didn't all of the probes and satellites sent beyond Mars travel through the astroid belt (and are still traveling through the Ort cloud)? They didn't seem to be damaged much.

Besides, I'd think that there would be more dust and other micrometeoroids around planets and in Lagrange points than in the interplantary regions of space. I am skeptical of this risk without evidence.

because you cant say "oops, got a problem, can you help?" nope.. one problem and you are 100% toasted.

Well, that argument applies to everything, really. One blown tire on the highway, and your car rolls or bike crashes. One mistake crossing the street and I'm roadkill. The best you can do is calculate the risks and prepare for the most likely senerios, but I am skeptical that the micrometeoroid density between the planets is risky.

Perhaps I am being a hostile student, but I ask for some studies or evidence before I accept your conclusion.

Does anybody know what's the difference between Hypernate and OJB?

I'm not sure about Hypernate, but here's a comparison of Java ORM tools, including Hibernate and OJB.

Insightful! I modified the (old) DataOwnership page on the Portland Pattern Repository's Wiki to include those other names. Could you read the changes, i.e. the first sentence, and make sure it is right (or correct it if wrong). Thanks in advance.

Insightful! I modified the (old) DataOwnership page on the Portland Pattern Repository's Wiki to include those other names. Could you read the changes, i.e. the first sentence, and make sure it is right (or correct it if wrong). Thanks in advance.

Using polymorphism instead of case/switch statements does NOT reduce code. It only moves it to a different spot. For a long, winding debate on this, see:

http://www.c2.com/cgi/wiki?SwitchStatementsSmell

As far as using function pointers (or their equiv.) in "GUI structures" being "OO", you are using a rather wide definition of OO. Interchanging code with data is much older than OO. OO is mostly about putting behavioral wrappers around data structures, not putting function references/pointers inside of structures.

1. http://developer.apple.com/documentation/WebObje cts/Enterprise_Objects/Introduction/chapter_2_sect ion_1.html
2. http://objectstyle.org/cayenne
3. http://www.theserverside.com/blogs/showblog.tss? id=CayenneAndHibernate
4. http://www.theserverside.com/articles/article.ts s?l=Cayenne
5. http://c2.com/cgi/wiki?ObjectRelationalToolCompa rison

An anonymous inner class in java can only refer to final variables from the local scope. So you define a final array with one element to copy something out of the inner class context.

Here is a good example:
http://c2.com/cgi/wiki?ClosuresThatWorkAroundFinal Limitation

I think the problem you are seeing is Ravioli Code; a (perhaps excessive) reaction to spaghetti code. Also Java (and probably C#) programmers seem to take Patterns too seriously as well, patterns should be descriptive, not prescriptive.