russellperry

I see your point, but I got the impression he was talking about a tactical/technical productivity boost rather than expanding their recruiting net or code expressiveness.

"...static typing becomes a big convenience in enforcing coherency across all the systems. You can guarantee that your dataflow is more or less going to work, and focus on the functional aspects...But as we move into a light-weight Service Oriented Architecture model, static typing becomes a genuine productivity boon."

A 'productivity boon'? I don't understand. At the risk of invoking the ancient static vs. dynamic religious war, this statement makes no sense to me.

I get that if your codebase is tangled enough, and your unit test suite is inadequate to "guarantee that your dataflow is more or less going to work" that maybe rewriting significant portions of it in a type-safe system makes sense. I guess. But without specific code examples it's hard to say exactly what he's talking about.

Myself, I've spent many years in both static and dynamic environments and I know exactly where I'm more productive -- and it's not wrestling complex parameterized types to the ground, pulling up abstract classes or interfaces, and/or configuring IOC containers, abstract factories and the like.

I wonder though -- this has echoes of Alex Payne's criticisms a couple of years ago, which I think Obie Fernandez addressed pretty well:

http://blog.obiefernandez.com/content/2009/04/my-reasoned-re...

True enough in general, but that cuts both ways -- I've worked with a number of longtime C++ guys that tend to optimize early, write long unreadable methods and seem positively allergic to standard OOP architectures, much less design patterns.

If you haven't watched Peepcode's Play by Play with Zed Shaw, you should. Really insightful stuff.

Zed's a strong cup of coffee and guys like him generally play a really healthy role in the community they are a part of, driving discussions in directions they might not have taken and playing the part of Gadfly at Large -- every community needs a Zed to keep from becoming complacent.

"Rails is a Ghetto" notwithstanding, Zed's writing is always worth engaging even when you strongly disagree. In that respect he's always reminded me of Steve Albini.

What Albini would do with Fret Wars, however, is another question entirely.

Sure, but in my experience the challenge of describing imperative instructions with tabular data (in general) makes the Object/Relational problem look one-dimensional.

Not knocking OP's efforts as a nifty academic excercise -- good stuff. But MSI is a real world (admittedly MS) attempt at writing imperative instructions into relational tables.

And, again...<shudder>

Anyone who thinks programming with tables is a neat idea hasn't had to write a complex Windows Installer/MSI deployment.

The horror...the horror...

I guess the part I should have emphasized better in my original comment was "in theory"...

Agree with all of this, and I've made the same arguments myself. That's one reason code coverage metrics are of limited use -- they can't measure the quality of the tests.

I wasn't intending to diminish the role of QA (essential) or assert that TDD cures all (doesn't), just that The Black Team weren't doing TDD.

OR in an agile/integrated testing environment, the Black Team would be working with the dev to help develop unit tests and/or find the bug before it was delivered.

Ruthless and thorough QA is a good thing, but has nothing to do with TDD. TDD should in theory help prevent the developer from ever hearing from the Black Team to begin with. If the Black Team found the bug, the dev's TDD fu wasn't strong enough.

Contrast could be better but I like the layout and fonts. Simple.

You'd also think a cisco engineer up to such shenanigans would know enough to use an anonymous/proxy whois registration.

Add Josh Bloch, Google's Chief Java Architect to that list.

"I almost never test at the view level, and barely at the controller level"

You sound like every Rails dev I know.

It depends on the controller action in question. If it's a boilerplate Rails controller action, then the ROI might not be that high, but if the controller is doing something more specific (assuming it's not doing something that ought to be pushed to the model) then unit testing the action is important, sometimes very important.

Code coverage is pretty much a meaningless metric because it can't say whether the tests are actually good and useful. But it can help point experienced devs into areas of risk that may or may not warrant more attention.

"Like Xerox and Kleenex, the popular usage is technically incorrect, but in practice, it doesn't matter."

The integrity of some acronyms is worth defending. I wouldn't want 'ACID' diluted to mean anything less than its strict definition, and I think the same holds true for 'REST'. The benefit of these distinctions is twofold: 1) we encourage the advantages of good RESTful practices and 2) we can communicate consistently without spending unnecessary effort qualifying our meaning. If REST means 'Anything but SOAP' then at some point we'll have to come up with another shorthand for 'Real REST' or spend lots of time re-stating the principles of REST every time we need to communicate architectural strategies that use them.

I should be able to say 'Singleton' or 'MVC' or 'ACID' and know that there is enough integrity to those ideas that a competent coder will know what I mean without me having to pseudo-code or UML the concept for them. The same should hold true for REST.

Romantic, starry-eyed, hopelessly idealistic and mostly true.

The problem I have with this theory is that Android just wasn't written as a general-purpose GUI framework/OS. It's very mobile and memory-constraint centric, and IMO would need a whole new UI layer, if not a major re-write at the OS level. Who would want to write tablet or netbook apps with the whole Activity/Intent structures, and listviews that populate dynamically when scrolling, or apps that the OS may kill at certain thresholds of memory pressure?

By this logic every language should have C-style headers. There's nothing to prevent me from creating a bloated API/interface with or without the framework forcing me to declare it external to the class, in interfaces, headers or otherwise.

In Eclipse it's as simple as using the refactor tool to 'pull up interface' from any God Class of my choosing.

Neither language nor framework can force a coder to apply the Single Responsibility Principle. Coders can be willy-nilly with or without interfaces.

There's some Western philosophical precedents for this tack as well. Heraclitus comes to mind, later Nietzsche, Kierkegaard. William of Occam I suppose would never allow 'classes' at all, only radically individual one-off objects.

Two modern philosophers that I think may provide a better conceptual foundation for a less reified/Platonic/Aristotelian/Formalist view would be Alfred North Whitehead and Henri Bergson, both of whom described the ingression or duration of individual substances into other substances. Rather than hard borders (interfaces?) that interact in static and unchangeable ways, substances actually change each other at these borders. Bergson in particular I think would be interesting at many levels of the SDLC -- from emergent design (he advocated an 'emergent' fingertip-feel, intuitive approach to Science) to the nature of objects and hierachies.

What about the notion that an interface can change/morph according to the client that consumes it? This would move towards a more Heraclitean/Whiteheadean/Bergsonian paradigm.

Yeah exactly! 'raise "not implemented"' is how I imitate abstract classes (on the rare occasion that I need them).

I get what you're saying, but Ruby already allows you to do this. If you like an API/design, then go ahead and reimplement it however you like. There are no class-level contracts anywhere in Ruby that would prevent this, and therefore interfaces provide no additional level of abstraction that Ruby doesn't already have.

This simply makes no sense in a Ruby idiom (and I'm not really sure this is the best way to think of it in Java either -- I can make an API public and well-documented with or without interfaces.)

I've used dozens of Ruby gems, plugins and classes over the years that have well-documented shared APIs and none of them (obviously) have had interfaces. Interfaces are good in certain environments for hiding implementation details where class-level contracts are enforced, but in Ruby this would provide no benefit at all.

Think of it this way: since Ruby has no class-level contracts, to some extent everything is already an interface. Everything is abstract. Every Ruby object has the opportunity to re-implement functionality in an abstract way.

"Kant's seperation between Phenomena and Noumena relates to the difference between interface and implementation, as well as to the concept of abstractions in general."

I'm not sure Kant would allow that phenomena are all that abstract. They're not eidetic/formal (although later Husserl would argue that they intend towards eidetic objects), they're merely the subjective experience of a particular thing. The (purely hypothetical) relationship between the noumena and phenomena are (naively and hypothetically) one-to-one, if there is any real relationship at all.

The n/p distinction is made by Kant not to emphasize the abstract nature of our mental experiences, but rather to emphasize a radical epistemic uncertainty regarding the objects that we would naively assume "exists" apart from the experience.

"Aristotle takes kind of the opposite tack - he is also very focused on building ontologies and taxonomies, but he views them as constructions of the intellect imposed upon their subjects, rather than being the most fundamental reality of the subject prior to its actual being."

Well, not exactly, and in fact this would turn Aristotle into his metaphysical opposite: a nominalist in the mold of Occam.

For Aristotle the formal cause of a substance is in fact absolute, every bit as real and 'prior' as with Plato, the big difference between the two being the question of epistemology, or how we become acquainted with the form to begin with. Yes, Aristotle argues that we know the form of a thing from experience, but the form of that thing, and the abstractions we produce from many experiences from similar things, are as real as with Plato and, as in Plato, point to higher, more organized spiritual structures that comprise ultimate reality.

Call me when somebody comes up with a Whitehead-ean programming paradigm.

I like the direction you're going here, but I would argue this structure is not unique to Kant. You could read Plato (or any idealist -- Schopenhauer or Philo or Hegel for that matter) the same way. The ontological structures are broadly the same, the difference lies in epistemology and the nature and origin of the formal epistemological structures to begin with.

Kant locates the origin of ideals/forms/categories in the mind only, as an essential pre-existing structure of the mind (think: hard-coded ROM), where Plato located their origins in reincarnate memory (not sure what the computer analogy would be there -- recycling a motherboard at Fry's?).

Allowing a class-level contract would fundamentally alter the dynamic nature of a language like Ruby. It might be cool (although I personally don't see the benefit), but it wouldn't be Ruby.

What mechanism would enforce the contract anyway? The best you could hope for would be a runtime error thrown when the interpreter detected the incompatibility, and you can do that manually now (I do it frequently to imitate abstract classes).

This might make sense for Clojure (I haven't used it) but in my years of Ruby programming (after 10 years in Java and C#) I have never thought to myself, man I'd love to have an interface here. Ruby's lack of class-level contracts is essential to its idiomatic nature, a strength not a weakness, imo.

"What if objects exist as encapsulations, and the communicate via messages? What if code re-use has nothing to do with inheritance, but uses composition, delegation, even old-fashioned helper objects or any technique the programmer deems fit? The ontology does not go away, but it is decoupled from the implementation. Here's how."

This is standard OOP 101 advice. 'Prefer encapsulation to inheritance' has been axiomatic in OO literature for over a decade. GOF and all the GOF-derived texts emphasize this.

OOP <> Inheritance

Inheritance is only one tool in the OOP toolbox, and probably one of the least important. OOP itself is only one conceptual tool in the programmer's toolbox, alongside procedural and functional tools. Learn them all, learn their strengths and weaknesses, and learn how to apply the right tool to the right problem.