Re: New paradigm of introspective OO development

[e-mail] (Jared Thirsk) wrote in
news:[e-mail]: 

> I am a recent SW engineering grad without several years 
> of serious programming work experience, so I present this
> with humility and an open mind.  I am hoping that people
> can direct me to a) why this is a bad idea, 

Hi there. I answer since I also have (used to have :) some
academic background in cognitive science, so I also have a
symphatetic ear. :) 

It's not that what you say is a bad idea - for what I've got 
of it, of course :-) - just that it usually takes both more
and less to talk of "new paradigm". 

Specifically, less general talk, and more details - formal,
or at least obviously formalizable - which show where your
approach is structurally different from the bunch of stuff
that's already there. Formalization is essential, imho,
since makes things compact and easier to read, it 
allows easy comparison between theories and generally, 
saying it academically, cuts the crap. :-) 

For talking of a "new paradigm" you shall - of course - 
start with a paradigm; and then have either one big
fundamental difference from which you descend a theory (say,
"the earth revolves around the sun and not the opposite":); 
or most often a number of smaller differences (for example 
"we bundle objects in self contained packages which 
incapsulate  complex behaviour and expose it in terms of 
service and properties" is one of the jumps between OO and
component-oriented approach) whose overall consequences
produce a structural difference in an existing theory. 

"Structural" meaning that you go down to the details and the 
difference is still there - and u cannot take it away. In
other words, you dont want just to say what's desireable,
but also how to do it and why and in which way that "how" is 
different or new. In jargon, you want a quantitative
approach rather than just qualitative (that, we leave to 
philosophers - ok, kidding ;-). 

For a number of reasons, it is less relevant whether or not
one paradigm can be implemented by another; but is important 
to identify exactly which mechanism is new (but can be 
translated/realized into some computation in another 
paradigm) and which structurally different. Now, in your 
post you have some heading like "Typing" (which tends to be 
a quite precise, formalized and throroughly explored 
concept) at the same level as "Flexibility" (which is in 
general a far from rigorous idea, and difficult to 
quantify). 

Take stuff like, for example, literate programming; or 
simply the differences between procedural and OO, 
functional/declarative approaches. What you have in each 
case is that you select some fundamental mechanisms for 
describing your problem space, and take the (more or less 
extreme) consequences. 

> b) what is out there that already does this, or c) that 
> this is an avenue worth exploring, or d) same as c and
> that they're interested in helping make it or e) something 
> else.  In addition to being someone who would like better 
> RAD tools for software development, 

Ideas are always worth exploring - keep in mind that fixing
'em or finding out that they're wrong is a good result in 
itself. What is imho important is the execution - the 
relenteless cutting, refinement and discarding of what is 
irrelevant, chaotic or not otherwise to the point.

Not that different from what makes a good software engineer, 
all in all :-) 

> I am also an independent researcher in the realm of
> psychology and cognitive science, and would like to see
> intuitive methods of programming that more closely
> represents good theory of mind (requiring less overall
> time and effort from the software developer), 

Yep, that's what most recent paradigms are all about. Not 
more computational power - which we probably can't anyway - 
but better efficiency. I'd like the start trek approach 
("Computer, do this") but I guess it'll take a while. :) 

> as well as a theory of mind (AI) that is easier to
> implement in and interact with software.

On this issue (which is probably somewhat OT here), there 
have been a number of efforts (of which you probably know 
more than me, since I havent done much reasarch in the 
fields since mid-90s). The key element I figured out at the 
time was language - specifically models to compute semantics 
of natural languages - which could have an huge impact: 
imagine software tools which could help you out defining 
models starting from a NL description, as much as a good 
s.e. does when talking to a customer. I won't be holding my
breath tough. :) 

-- 
You dont know what to do when you dont know what you're 
doing.
http://space.tin.it/computer/csadun