Imperative, declarative, functional, and... ???
-
How about these: Pedantic: Standards it may implement, but work it may not. Aromatic: It may work, but there are these smells coming from the great steaming pile of source. Pragmatic: Ugly, but it works.
Software Zen:
delete this;I like where you are coming from Gary. It is really quite funny, however, I think that I have used all of your methods or paradigms at some point. The aromatic is probably the worst, as it hangs around, and comes wafting back to haunt you. Pragmatic is the best as long as you don't have to update it in 5 years time. I have not and have never been a pedant. ...and never will be.
-
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. :)
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
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?
Sometimes i do, but i always end up on OO. :-D
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
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. :-D
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
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. :)
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
ah but that's the beauty of it see.. they wont understand it, but being the boss they cant admit that. :laugh:
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.
-
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
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#Are you thinking of the usage definition of paradigm or the actual definition of paradigm? What's the difference? Usage definition is an implied definition based on how a word is used. A good example is the use of the word might: Might is actually the past tense of may, however, it is mostly used to imply possibility. "It might come to that." "May I enter?" - "You might." In this proper use permission is presumed to have already been given. What specifically do you not like about the word paradigm? Actual definition from: http://dictionary.reference.com/browse/paradigm?s=t[^] par·a·digm [par-uh-dahym, -dim] Show IPA noun 1. Grammar . a. a set of forms all of which contain a particular element, especially the set of all inflected forms based on a single stem or theme. b. a display in fixed arrangement of such a set, as boy, boy's, boys, boys'. 2. an example serving as a model; pattern.
-
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. :-O Besides that, I don't do a lot of hammering these days so it's all good for me. :-D
-
"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. :-O Besides that, I don't do a lot of hammering these days so it's all good for me. :-D
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.
-
Interrogative. Ve ask the qvestions.
I wanna be a eunuchs developer! Pass me a bread knife!
my data structures teacher actually said that prolog was an example of interrogative programming X|
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)
-
my data structures teacher actually said that prolog was an example of interrogative programming X|
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!
-
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
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#I would add OO personally, but with the caveat that I mean the Smalltalk style of message-based OO, not the half-hearted imitation in most supposedly OO languages. There is a major difference when even constructs such as conditionals and loops are implemented using message-passing. I heartily recommend most dev's to attempt a small project in one of these languages, much as people recommend using functional languages for a project. You don't really grok OO until you've used one of these. Also, isn't functional programming declarative by nature?
-
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
1. Set a value. 2. Test a value. 3. Jump to an instruction that sets or tests a value. I think you may need to reevaluate functional programming.
-
"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. :-O Besides that, I don't do a lot of hammering these days so it's all good for me. :-D
-
1. Set a value. 2. Test a value. 3. Jump to an instruction that sets or tests a value. I think you may need to reevaluate functional programming.
Feel free to enlighten me on anything you can do in any platform, in any language, in any paradigm that does something outside of those three things.
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