Can someone please tell me whether calling Procedural Programming as Procedural Oriented Programming is correct or not?
I'd say 'procedural programming' is correct and more common. However, since it's often contrasted with object-oriented programming, 'procedural-oriented programming' has become more common.
I'd say it's technically wrong though. First off, they're not opposed, you can have an object-oriented procedural language and do both. Secondly, a procedural language is procedural, not just 'procedure-oriented'. Similarly, some people call specific languages that are more object-oriented than others by design 'object-based'.
Another cause for confusion may be protocol-oriented programming (pop), which is an acronym that is sometimes (incorrectly) associated with procedural programming.
Wikipedia provides a good overview of the common programming paradigms and their correct names https://en.wikipedia.org/wiki/Comparison_of_programming_paradigms
From what I have studied, procedural programming is correct . This approach focuses more on the process.
Related
I've done some research about Lua programming but I'm still confused about under which paradigm it can work.
In some walkthroughs, I've found that Lua is not made for Object-Oriented Programming. But they are other people that says it can work too for OOP. So, I'm looking in which programming paradigms it can work the best.
Lua is a "do what you want to" programming language. It doesn't pick paradigms; it is a bag of useful features that give you the freedom to use whatever paradigm that you need. It doesn't have functional language features, but it does feature functions as first-class objects and proper lexical scoping. So you can use it functionally if you so desire. It doesn't have "classes" or other such prototypes, but it does feature ways to encapsulate data and special syntax for calling a function with a "this" object. So you can use it to build objects.
Lua does not dictate what you do with it; that's up to you. It provides low-level tools that allow you to easily build whatever paradigm you wish.
Lua is an imperative language; so it is not ideal for functional programming.
Left by itself, Lua is a procedural language. However, given the simplicity of its data structures (it just has one: the table) it's very easy to add a "layer" on top of it and make it an object oriented language. The most basic inheritance rule can be achieved in as little as 10 lines of code. There are several libraries out there that provide a more refined experience though. My library, middleclass, is 140 LOC in total.
Another great way of using Lua is as an scripting language. It's small, fast, uses only standard C stuff, and it's standard lib is tiny. On the other hand, it doesn't come with "batteries included" like java does.
Finally, I find it very useful as a data notation language; you can express raw data in a format very similar to JSON.
In general, I think that Lua feels very close to javascript.
What would be a valid reason(s) to use objects in functional programming languages? I see that f# is a functional programming language that lends heavily on the object side when dealing with the .net ecosystem of classes. But apart from this interaction with other assemblies/programs maybe written in c#, why would anyone choose to use objects for decomposition of a program in a function oriented language or style?
Does mixing up a style of program prove a help or a hindrance?
Functional and object oriented designs make different types of extensions easy. Given a discriminated union in a functional setting, it's easy to define any number of functions which work on that type, but it's hard to add additional cases to the type, since that would require going back to add the additional case to each function which pattern matches on the type. On the other hand, given a base type (or interface) an OO setting, it's easy to add new subtypes, but adding new operations to the base type is hard, since it potentially requires modifying existing subtypes to add an implementation of the new operation to each one.
Depending on the type of extensibility that's most relevant to the task at hand, either the functional or the object oriented approach may make more sense, so it's nice to have both options available. One popular approach is to use a functional approach "in the small" and an OO approach "in the large" (e.g. it's mentioned in this podcast with Luke Hoban).
Objects provide encapsulation that makes large-scale programming easier.
What would be a valid reason(s) to use objects in functional programming languages?
Objects are used in functional languages for a variety of reasons:
Large-scale structuring of programs.
Interoperability with existing OOP code (e.g. on the JVM or CLR).
Problems for which the ability to extend class hierarchies with more classes is a natural fit.
Does mixing up a style of program prove a help or a hindrance?
Can be a help but it would not be a good idea to do it without good reason.
Got an idea: functions (in FP) could be composed similar ways as components in OOP. For components in OOP we use interfaces. For functions we could use delegates. Goal is to achieve decomposition, modularity and interchangeability. We could employ dependency injection to make it easier.
I tried to find something about the topic. No luck. Probably because there are no functional programs big enough to need this? While searching for enterprise scale applications written in FP I found this list.
Functional Programming in the Real World and this paper.
I hope I just missed the killer applications for FP, which would be big enough to deserve decomposition.
Question: Could you show decent real-world FP application (preferably open source), which uses decomposition into modules?
Bonus chatter: What is the usual pattern used? What kind of functions are usually decomposed into separate modules? Are the implementations ever mocked for testing purposes?
Some time ago I was learning F# and wondering about the same topics, so I asked about quality open source projects to learn from.
The reason why you're not seeing anything similar to dependency injection in functional programming is that it's just "natural", because you "inject dependencies" just by passing or composing functions. Or as this article puts it, "Functional dependency injection == currying", but that's just one mechanism.
Mocking frameworks are not necessary. If you need to mock something, you just pass a "stub" function.
See also this question about real-world Scala applications.
Either we're talking at cross-purposes (it's possible: I'm rather unfamiliar with OOP terminology) or you're missing a lot about functional programming. Modules and abstraction (i.e. interchangability) were basically invented in the functional language CLU. The seminal papers on abstract types are James Morris's Protection in programming languages and Types are not sets. Later, most improvements in module systems and abstraction have come from the functional programming world, through ML-like languages.
The killer application for functional programming is often said to be symbolic manipulation. Most compilers for functional languages are written in the language itself, so you could look up the source of your favorite functional language implementation. But pretty much any nontrivial program (functional or not) is written in a modular way to some extent — maybe I'm missing something about what you mean by “decomposition”? The modularity will be more visible and use more advanced concepts in strongly typed languages with an advanced module system, such as Standard ML and Objective Caml.
I recently began to read some F# related literature, speaking of "Real World Functional Programming" and "Expert F#" e. g.. At the beginning it's easy, because I have some background in Haskell, and know C#. But when it comes to "Language Oriented Programming" I just don't get it. - I read some explanations and it's like reading an academic paper that gets more abstract and strange with every sentence.
Does anybody have an easy example for that kind of stuff and how it compares to existing paradigms? It's not just academic fantasy, isn't it? ;)
Thanks,
wishi
Language oriented program (LOP) can be used to describe any of the following.
Creating an external language (DSL)
This is perhaps the most common use of LOP, and is where you have a specific domain - such as UPS shipping packages via transit types through routes, etc. Rather than try to encode all of these domain-specific entities inside of program code, you rather create a separate programming language for just that domain. So you can encode your problem in a separate, external language.
Creating an internal language
Sometimes you want your program code to look less like 'code' and map more closely to the problem domain. That is, have the code 'read more naturally'. A fluent interface is an example of this: Fluent Interface. Also, F# has Active Patterns which support this quite well.
I wrote a blog post on LOP a while back that provides some code examples.
F# has a few mechanisms for doing programming in a style one might call "language-oriented".
First, the syntax niceties (function calls don't need parentheses, can define own infix operators, ...) make it so that many user-defined libraries have the appearance of embedded DSLs.
Second, the F# "quotations" mechanism can enable you to quote code and then run it with an alternative semantics/evaluation engine.
Third, F# "computation expressions" (aka workflows, monads, ...) also provide a way to provide a type of alternative semantics for certain blocks of code.
All of these kinda fall into the EDSL category.
In Object Oriented Programming, you try to model a problem using Objects. You can then connect those Objects together to perform functions...and in the end solve the original problem.
In Language Oriented Programming, rather than use an existing Object Oriented or Functional Programming Language, you design a new Domain Specific Language that is best suited to efficiently solve your problem.
The term language Oriented Programming may be overloaded in that it might have different meanings to different people.
But in terms of how I've used it, it means that you create a DSL(http://en.wikipedia.org/wiki/Domain_Specific_Language) before you start to solve your problem.
Once your DSL is created you would then write your program in terms of the DSL.
The idea being that your DSL is more suited to expressing the problem than a General purpose language would be.
Some examples would be the make file syntax or Ruby on Rails ActiveRecord class.
I haven't directly used language oriented programming in real-world situations (creating an actual language), but it is useful to think about and helps design better domain-driven objects.
In a sense, any real-world development in Lisp or Scheme can be considered "language-oriented," since you are developing the "language" of your application and its abstract tree as you code along. Cucumber is another real-world example I've heard about.
Please note that there are some problems to this approach (and any domain-driven approach) in real-world development. One major problem that I've dealt with before is mismatch between the logic that makes sense in the domain and the logic that makes sense in software. Domain (business) logic can be extremely convoluted and senseless - and causes domain models to break down.
An easy example of a domain-specific language, mentioned here, is SQL. Also: UNIX shell scripts.
Of course, if you are doing a lot of basic ops and have a lot of overlap with the underlying language, it is probably overengineering.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
From day 1 of my programming career, I started with object-oriented programming. However, I'm interested in learning other paradigms (something which I've said here on SO a number of times is a good thing, but I haven't had the time to do). I think I'm not only ready, but have the time, so I'll be starting functional programming with F#.
However, I'm not sure how to structure much less design applications. I'm used to the one-class-per-file and class-noun/function-verb ideas in OO programming. How do you design and structure functional applications?
Read the SICP.
Also, there is a PDF Version available.
You might want to check out a recent blog entry of mine: How does functional programming affect the structure of your code?
At a high level, an OO design methodology is still quite useful for structuring an F# program, but you'll find this breaking down (more exceptions to the rule) as you get down to lower levels. At a physical level, "one class per file" will not work in all cases, as mutually recursive types need to be defined in the same file (type Class1 = ... and Class2 = ...), and a bit of your code may reside in "free" functions not bound to a particular class (this is what F# "module"s are good for). The file-ordering constraints in F# will also force you to think critically about the dependencies among types in your program; this is a double-edged sword, as it may take more work/thought to untangle high-level dependencies, but will yield programs that are organized in a way that always makes them approachable (as the most primitive entities always come first and you can always read a program from 'top to bottom' and have new things introduced one-by-one, rather than just start looking a directory full of files of code and not know 'where to start').
How to Design Programs is all about this (at tiresome length, using Scheme instead of F#, but the principles carry over). Briefly, your code mirrors your datatypes; this idea goes back to old-fashioned "structured programming", only functional programming is more explicit about it, and with fancier datatypes.
Given that modern functional languages (i.e. not lisps) by default use early-bound polymorphic functions (efficiently), and that object-orientation is just a particular way of arranging to have polymorphic functions, it's not really very different, if you know how to design properly encapsulated classes.
Lisps use late-binding to achieve a similar effect. To be honest, there's not much difference, except that you don't explictly declare the structure of types.
If you've programmed extensively with C++ template functions, then you probably have an idea already.
In any case, the answer is small "classes" and instead of modifying internal state, you have to return a new version with different state.
F# provides the conventional OO approachs for large-scale structured programming (e.g. interfaces) and does not attempt to provide the experimental approaches pioneered in languages like OCaml (e.g. functors).
Consequently, the large-scale structuring of F# programs is essentially the same as that of C# programs.
Functional programming is a different paradigm for sure. Perhaps the easiest way to wrap your head around it is to insist that the design be laid out using a flow chart. Each function is distinct, no inheritance, no polymorphism, distinct. The data is passed around from function to function to make deletions, updates, insertion, and create new data.
On structuring functional programs:
While OO languages structure the code with classes, functional languages structure it with modules. Objects contain state and methods, modules contain data types and functions. In both cases the structural units group data types together with related behavior. Both paradigms have tools for building and enforcing abstraction barriers.
I would highly recommend picking a functional programming language you are comfortable with (F#, OCaml, Haskell, or Scheme) and taking a long look at how its standard library is structured.
Compare, for example, the OCaml Stack module with System.Collections.Generic.Stack from .NET or a similar collection in Java.
It is all about pure functions and how to compose them to build larger abstractions. This is actually a hard problem for which a robust mathematical background is needed. Luckily, there are several patterns with deep formal and practical research available. On Functional and Reactive Domain Modeling Debasish Ghosh explores this topic further and puts together several practical scenarios applying pure functional patterns:
Functional and Reactive Domain Modeling teaches you how to think of
the domain model in terms of pure functions and how to compose them to
build larger abstractions. You will start with the basics of
functional programming and gradually progress to the advanced concepts
and patterns that you need to know to implement complex domain models.
The book demonstrates how advanced FP patterns like algebraic data
types, typeclass based design, and isolation of side-effects can make
your model compose for readability and verifiability.