|
Was wondering this morning what other programming paradigms there are (I'm putting OO into the imperative category.) For example, I think "asynchronous" might fit into this list, but what it really begs for is a definition of what this list actually is - I'm not happy with the word "paradigm". So, I have two questions - first, can you come up with a more concrete definition of this list, rather than just the word "paradigm", and what else do you think fits into this list?
You could look at this post[^] but I don't think it contributed anything much to the actual question (though lots of good discussion on the 3 paradigms), and one person replied "Are there more exotic types? Not yet."
Really? Not yet? Hmmm....
Marc
|
|
|
|
|
Marc Clifton wrote: first, can you come up with a more concrete definition of this list, rather than just the word "paradigm", and what else do you think fits into this list?
Sounds like a homework question to me... 
On a more serious note though, I agree about the word paradigm. It doesn't exactly fit the bill, but I don't really have a better suggestion at the moment...
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill
America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde
Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
|
|
|
|
|
Colin Mullikin wrote: Sounds like a homework question to me...
Yeah, I almost put in a disclaimer but figured, everyone should know me better than that! 
Colin Mullikin wrote: but I don't really have a better suggestion at the moment...
Neither do I, that's why I figured I'd toss the question to the wolves and see what comes up. 
Marc
|
|
|
|
|
Interrogative.
Ve ask the qvestions.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark Wallace wrote: Interrogative.
Heh - there might actually be something there.
Marc
|
|
|
|
|
my data structures teacher actually said that prolog was an example of interrogative programming 
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
Well, some of the Prolog examples I've seen have certainly been WTF???
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
What would make another type, exotic? Seems like an attempt to promote something because of it's properties rather than it's usefullness.
As far as another word for paradigm, it could be replaced with philosophy, dogma, religion(?). I'm too much of a practical programmer, so it's just another word that won't help solve things. Do people really look at a problem and decide what paradigm would best be used to solve it?
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Chris Meech wrote: Do people really look at a problem and decide what paradigm would best be used to solve it?
Probably not, but they might need to write something that sounds fancy for the boss
Beauty is in the eye of the beer-holder
Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow.
You can't scare me, I have children.
|
|
|
|
|
Naa, bosses rarely understand such things, i could say that i'm going to program using a functional declarative object oriented paradigm, and they never will catch what it means.
|
|
|
|
|
ah but that's the beauty of it see.. they wont understand it, but being the boss they cant admit that.
Beauty is in the eye of the beer-holder
Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow.
You can't scare me, I have children.
|
|
|
|
|
Chris Meech wrote: Do people really look at a problem and decide what paradigm would best be used to solve it?
Possibly, but I think what people mostly do is figure that out somewhat unconsciously. For example, if I need some sort of iteration that's not not provided by the framework, I might realize that I could generalize the iteration because I don't know what the next guy might want to do with each element, so I write a functional representation of the iteration that lets the programmer pass in a lambda expression, and I've just implemented a "functional paradigm" solution.
Or I use an enumerable and a yield and I've implemented an imperative paradigm.
Or I leverage an IoC framework to glue the handler to the iterator through an XML statement an lo, I have implemented a declarative paradigm.
So, without really putting much thought into it, I end up with some implementation, and I'm going to contend that when we look at a problem, yes, we really should decide what paradigm would be best to solve it, we really should be more conscious about the decision process.
Marc
|
|
|
|
|
Chris Meech wrote: Do people really look at a problem and decide what paradigm would best be used
to solve it?
Sometimes i do, but i always end up on OO. 
|
|
|
|
|
RafagaX wrote:
Chris Meech wrote: Do people really look at a problem and
decide what paradigm would best be used
to solve it?
If you've got a hammer - every problem looks like a nail!
|
|
|
|
|
"If you've got a hammer - every problem looks like a nail!"
I have read that statement many times and I think it is quite inaccurate.
My point of view is due to the fact that if I have a hammer and I am frustrated, the hammer being readily at hand is what I am gong to use to smash the thing that is frustrating me. And that is regardless of whether it looks like a nail or not.
On the other hand, if I have a baseball bat handy, I'm a gonna swing and hit whatever it is that is frustrating me.
If I have a gun, I will shoot whatever is frustrating me.
This is why I do not keep a hammer handy (meaning I generally forget where I last placed it), and own neither bat nor gun.
To date: I have smashed anything with the hammer unless it is in fact a nail, and have not utilized a bat or gun to eliminate those things that frustrate me.
I realize that constantly misplacing a hammer wastes time in finding it when one has nails to hammer, however, the time it takes to find the hammer tends to be enough time for me to settle down and decide that smashing the computer will not solve the problem.  Besides that, I don't do a lot of hammering these days so it's all good for me.
|
|
|
|
|
satovey wrote: "If you've got a hammer - every problem looks like a nail!"
I have read that statement many times and I think it is quite inaccurate.
I have experienced that metaphor many times, and it is absolutely accurate, at least for metal tools. The key is to realize that with mental tools, you always have every mental tool you know about.
Think about that statement this way:
If all you had was a hammer, and you didn't know screwdrivers existed, and you saw a screw, wouldn't you try to fasten two boards together by applying the hammer to the screw as if it were a nail?
Maybe, if you were really, really smart, and not in a hurry, you'd notice it is different than a nail and try and discover if there was another way it could be used to fasten two boards together. For most though, they'd apply hammer to screw and get their boards fastened together.
For mental tools, such as we use in programming, problem solving is often limited by the techniques we know (our "tools").
Lets consider a concreate sorting example.. if all one knows is that there's a sort routine in their library, isn't that going to be the first tool they choose to sort two very large, pre-sorted arrays into a single, much larger, sorted array? Are they going to declare the problem insolvable when the arrays are so large they don't fit into memory? Someone else with other sorting tools in their mental toolbox will simply pull out another one, implement it if needed, and get the job done.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
I'm happy that it doesn't apply to you.
|
|
|
|
|
Oh there are many many more...
http://en.wikipedia.org/wiki/Programming_paradigm[^]
I for one have no quarrels with the word "paradigm". I think it is wise to remember that the paradigms cover different aspects (as well as properties) of a programming language. In other words paradigms are not necessarily mutually exclusive.
(And BTW, there is no direct correlation between OO and imperative, according to the above link.)
Life is too shor
|
|
|
|
|
|
According to wikipedia OO should be considered as it's own paradigm, as should machine code and assembly language. It would depend on whether you want to class all of those as imperative or not. Technically they are, but is that really a useful definition?
My thinking is that it depends what level of abstraction you want to consider: if you want to talk in the abstract it's hard to think of other major classes of language, but equally when describing the properties of a language by paradigm it's better to have more words than fewer, even if OO and procedural boil down to being imperative - I could say "C# is an imperative language, and so is machine code" but it's so abstract as to not give any useful information, whereas if I said "C# is an OO language, and machine code is an imperative language" then this at least starts to hint at the fundamental differences in how you would use both.
And I don't particularly have a problem with the word paradigm in this context as to me it would imply a different way of thinking about how to structure the program, which taking OO vs structured programming as an example makes sense as, even though they are both still imperative, you think about their structure differently.
|
|
|
|
|
c2423 wrote: My thinking is that it depends what level of abstraction you want to consider:
Good points, all. I appreciate the feedback!
Marc
|
|
|
|
|
imperative, declarative, functional, scripting, and OO. At least that is from the list in 1301.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: imperative, declarative, functional, scripting, and OO.
Thanks!
Marc
|
|
|
|
|
Subjunctive
"The program would work better if it had been written by someone competent."
|
|
|
|
|
Functional and imperative are the same thing. You only really do three things in programming. Ever.
1. Set a value.
2. Test a value.
3. Jump to an instruction that sets or tests a value.
Noop doesn't count.
I come from a lit background so I think in these terms:
The declarative: this sets a value. It could be memory, registers, whatever. If you remember, back in the 1980's you would change what was on the monitor by simply writing directly to video memory using BASIC PUT.
The inquisitive: this tests a value. If could be an if, for, or while statement.
The imperative: go do something. Jump to another instruction.
Everything is in the present tense.
I've always kind of wondered how we could introduce the past and future tense into programming.
To incorporate the past tense in to programming you would have to know the past states of objects to effectively use it.
To incorporate the future tense you have to predict the states of objects. A past tense algorithm could help to predict trends of objects.
Also, the modal verb "may" is interesting for statistical analysis. For example:
may i = 1;
Well, i may be 1, or it may not be one. Or...
may i = {1, 3, 5, 7, 9};
where i may be initialized to any of the values in the set.
I think, if we also look at other language structures, we might come up compelling structures to use in describing algorithms.
However, it still all comes back down to the basics of setting, testing, and jumping and you just can't get away from that.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
In most cases the only difference between disappointment and depression is your level of commitment. -- Marc Maron
I am not a chatbot
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
