All the Perl that's Practical to Extract and Report
use Perl Log In
luqui (5770)
The fourth paradigm is...
Okay, I thought about this some. I walked around the house, talked to myself, played with some fresh fruit (moving them here and there, describing their properties), and I think I've come up with a very vague idea of this fourth control paradigm.
First, here's how I started. I figured, I'm trying to classify the three existing control paradigms (imperative, functional, logical) into two orthogonal properties. Well, it has to be one of these:
A B
X | Imperative | Functional |
Y | Logical | ??? |
A B
X | Functional | Imperative |
Y | Logical | ??? |
A B
X | Logical | Functional |
Y | Imperative | ??? |
That covers all the possible cases. I then did a little scanning back and forth, and settled on the second diagram, where A ~~ "doesn't change anything" and B ~~ "does change something". Then I did some brainstorming to figure out what X and Y were based on that.
And I think this is it: You give a functional program an object, and it tells you some property of the object (these can be very complex objects and properties, but it ultimately reduces to that). You give a logical program a property, and it gives you an object that satisfies that.
Then, the imperative parallel is: You give an imperative program an *action* and it tells you the result. So, the fourth paradigm is the converse of this; a generalized inverse kinematics engine: you give it a result, and it tells you the action.
A prime example of this kind of paradigm is the UNIX diff program. You give it a file, and the result of some action on that file, and it tells you how to modify the original to get the result. Also, in gaming, pathfinding and inverse kinematics (the process of finding how to move, say, a human body from one position to another in a physically sound way) are both examples of this paradigm.
So what does a language that enables this paradigm look like? And what would you name it?
Or is it a BUG?"
"Let's call it an accidental feature. :-)"
--Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
FWIW (Score:1)
What we learn in these classes is, respectively, Functional, Imperative, Logic and OO programming.
In my case, this was done mostly with Haskell, C, Prolog and Java (sometimes they change the languages).
There was also a teacher who used to say that databases are a paradigm on its own.
Also, I was first introduced to Perl in the classes of "Scripting as a Programming Paradigm".
Re:FWIW (Score:1)
> Functional, Imperative, Logic and OO programming.
Yep, those are the four that I identified in my last post. However, I argue that OO is an "abstraction style", and not a "control style", which is what I'm looking for.
Re:FWIW (Score:1)
If you want a control style, where does event-driven programming fit? What if it's asynchronous?
Re:FWIW (Score:1)
> event-driven programming fit? What if it's
> asynchronous?
I define the control paradigm by the input (code) and the output (what happens when you run it). In the event driven case, you give it actions to execute when certain things happen. But the first part is the important part, you're giving it actions, and it tells you what happens when those actions are executed, even though those actions are triggered rather than sequenced. Therefore, I think event
Hmm... (Score:2)
Re:Hmm... (Score:1)
Re:Hmm... (Score:1)
Bill
# I had a sig when sigs were cool
use Sig;
Re:Hmm... (Score:1)
> relaxation / constraint techniques like the
> Simplex method of Linear programming?
The only thing I know about linear programming is that my grad-student friend is taking a course in it and he's working his ass off...
Genetic algorithms are an interesting idea for this control style. My thinking (and my toy implementation [luqui.org]) was that you would specify a class of functions, and it would find which function in that class that mapped a given input to a g
I should have read this before replying before (Score:1)
The fourth paradigm (Score:1)