Web programming is functional programming (Web programming is functional programming)

Web programming is functional programming

Everyone who has long programmed for both worlds, that is he has developed local applications and programmed for web, will tell you that web programming is very different from classical application development. and it's not just the programming language. you can develop both local and web applications using the same Java, Python or even C ++. the difference lies in the medium of the web. it defines a much different deployment and runtime environment. it implements a different service model. it imposes different application architecture. it CILS for a different programmer mentality because the very philosophy of the web is miles away from the traditional programming school. and here with the web programming paradigm we have something interesting to recognize. very obvious actually but shadowed into the background by the march of the modern powerful programming paradigms and drowned by the fanfares of new and shining technologies and tools.

"What's that? "-Will you ask.

Let us see.

We'll start by looking at the lifecycle of a typical local application and compare it with that of a typical web application. I will be using the term "lifecycle" to refer to a period of application activity, its runtime, not in the sense of the project lifecycle with its different development and maintenance stages.

What is the lifecycle of a typical local application like? A user starts the application, it gets loaded into memory and now it is running. it can react to user input, load files from disk or send some data over network. it can interact with the other software or hardware components, invoke other services or react to an external invocation. it can gather data, accumulate it and process it in some way. in short, all those things a local application wocould do while it's up and running.

How does the lifecycle of a typical web application look like? A user clicks a link in his browser. the browser sends a request to a web server, then has es a response and shows it back to the user. quite simple actually. but the application is not running in the browser on the user machine. it's running on the web server. and there, the application is not running continuously. the server only briefly brings the application into life to accomplish the task of processing the request and preparing a reply. it happens in a blink of an eye. the application is not running between requests. it is invoked for a short time and shut down immediately after it's done with the request. and the application is not even entirely loaded into memory, only the parts of it really necessary for the task at hand. you cocould say a web application has an instantaneous lifecycle. only its runtime environment that is the web server is running continuously. there are sure workarounds like session and data serialization to help keep data between the application lifetimes and to mimic the stateful operation like certain frameworks such as ASP. NET WebForms or JSF do, but still, these are just technical tricks and actually a story for another time. we shall focus on usual web applications focused around und processing requests. and those web applications enjoy a very brief runtime existence.

For a development of a local application, a number of techniques wowould prove useful. object-oriented approach to structure the problem domain and help deal with its complexity. certain design patterns for an effective tive and an elegant solution. layered architecture to split code responsibilities and minimize dependencies. these are all classical best practices which have proven efficient in development of local applications.

Using them in web development is a different story entirely. we actively use object-oriented approach to define a domain model, we adopt certain design patterns and we implement the layered architecture. they improve code quality, add reusability, structure the application in conceptual modules. it all works and belongs to the everyday routine. even so, I can't often help but notice that these things seem to be redundant, an oversolution to really small problems. at times I just look at the smart and sophisticated code and catch myself on the random thought to be willing to strip it all away and just do things straight.

What's straight? Think of a typical routine as an application is processing a request. What happens there, in major steps? The application processes es the user input, validates it, transforms it into a domain-specific format and passes it to an SQL code which puts it into the database. What happens next? The code reads some other data from the database, reformats it to be user-friendly then serves back a piece of HTML. that's it. that's what happens under the hood of most web applications. no fancy objects living their lives, sending and processing messages and intelligently interacting among themselves to achieve a higher behavior. no, just some data traveling between the user and the database, back and forth. it's data-flow one-on-one. and the code that implements that is essential when Ming as functional code, regardless of the style it was conceived to bear.

This discussion touches the subject: Is functional programming relevant to web development? As one user eloquently put it:

"Functional programming matches web apps very well. The web app has es a HTTP request and produces a HTML result. This cocould be considered a function from requests to pages ."

And I wocould add the following. the code which implements this function bears essential the functional style. instead of true objects keeping the application state in memory and cooperating to implement the application logic, we 've got a database to keep the state of the application and the entire code is basically a large and complex function that arranges for the specified dataflow to reach its destinations, either the database or the user.

What lesson can we take from this? It's not always good to fanatically force the object-oriented style and the complex architecture into web applications. they wocould not necessary profit from this approach but cocould instead get overcomplicated and inefficient in terms of performance and later maintenance. one must always weigh the pros and cons of this approach on a per-project basis.

And when a programmer codes a web application and suddenly it bears the imprint of a functional programming style, he shocould not get immediately criticized and ridiculed. maybe he did it on purpose. or maybe it was the unconscious manifestation of the subtle understanding that web programming is functional by nature.

Readers 'commentsyour statements "... functional style... "and "... database to keep the state... "are contradicloud. the whole essence of the functional style is to avoid state. state is the antithesis of the funtional style.

If a = f (x) in the functional world then for the same x, a always takes on the same value. In a world with state, a can take on any value.

Calling a web page with the same input (post for example) and getting the same output (HTML) is functional

Anonymous 9 NOVEMBER 2010, This article has proven my thoughts and experience. I have recently started to learn C # and now it is much clearer what I was confused with PHP. PHP and object orientation a little bit seems "forceded" to me. something to do just because is cool and can be done. practically, I was contemplating during months why to do this and that in oo way in php if you can without it-and easier. normally, as you stated, you make a request (no need to instantiate multiple object from the same class, etc) and display the answer in HTML format in the browser. in C #, it is clear the why for oop.
Oo php smells hype, but need to follow the mainstream.
Thanks for the article, bookmarked on delicious! Anonymous 9 NOVEMBER 2010, I totally agree with you.
I cocould feel it with pain when working in Java in bad designed web application,
And with joy when working with functional ages.

An interesting way to manage state, while still being functional is continuation based framework. there is one in Plt-scheme (now called racket ). there is Seaside too, but obviously it is less functional, because it is SmallTalk.

I experienced with Haskell and Yesod and found it very interesting, but I am not yet confortable with it.

Another way of doing is the Sinatra way in Ruby (or Flask in Python). Not really functional, but a lot simpler than most framework.

While I agree with you for CRUD application, I'm still thinking for application that do have business logic.
I'm not satisfied with working with semi-structured business model. Which happen when you start from a CRUD design and have to add logic later.
I'm not satisfied with putting the logic in the database. If SQL, it is a big NO. If MongoDB or CouchDB, better, but I don't like the idea.
How wocould you do? Jean-Baptiste Potonnier 10 NOVEMBER 2010, @ Anonymous: Yes, on a purely conceptual level you are correct. the whole program of a web application cannot be regarded as a functional program. at least in practice there are always except tions, workarounds and framework tricks to break the idea of a purely functional style. however, if we consider the database data for what it in most cases is-just data but not the state, then the program may become functional as it will just be taking this data as input and returning it as output. and the number of possible input variations of "x" for a function of f (x) will be unlimited.

@ Jean-Baptiste Potonnier: Thanks for the new term for me-"continuation-based framework ". didn't know this state-preserving concept had an official name. anyway, from my experience with the WebForms framework (this shocould also fall into this classification) you definitely cocould and probably shocould build up an object-oriented architecture encompassing domain objects and business rules. these frameworks actually turn what you wowould call web sites into web applications. for a site-type application you cocould stay with functional style, but for an application-type project an object-oriented architecture might give you an edge. but again, it all depends on a project, its size and its function.

Developer Art 12 NOVEMBER 2010, Leave your comment

Anyone who has been developing both local and Web applications in two fields will tell you that Web application development is very different from traditional application development. This is not a programming language. Using Java, Python, and even C ++, you can develop both local applications and Web applications. The difference lies in the Web carrier media. It shows a completely different deployment and running environment. It implements a different service mode. It uses a different application architecture. It requires programmers to adopt a different way of thinking, because the philosophical system embodied in Web programming is far from our traditional programming faction. Here, we need to understand some interesting things about the Web programming paradigm. Although it is obvious and true, It is shaded by the strong modern programming paradigm and overwhelmed by the glare of new technologies and tools.

"What is it ?" -You will ask.

Let's take a look.

Let's take a look at the lifecycle of a typical local application and compare it with that of a typical Web application. I will always use the term "Life Cycle" to represent the activity cycle of the application. during runtime, it does not refer to the project cycle that includes different development and maintenance phases.

What is the life cycle of a typical local application? A user starts this program and the program is loaded into the memory to start running. It can respond to user input, read files from the disk, or transmit data over the network. It can interact with other software or hardware, call other services, or respond to an external call. It can collect, accumulate, and process data in some way. In short, these are all things that can be done when a local application is started.

What is the life cycle of a typical Web application? The user clicks a link in the browser. The browser sends a request to the Web server, receives the response, and displays it to the user. Very simple. However, applications are not running in browsers on users' machines. It runs on the Web server. The application is not running continuously. The server only wakes up the application for a short time to complete the request processing task and prepares the response. These things happen in the twinkling of an eye. The application is not running between two requests. It is only called for a short period of time. It stops running immediately after the request service is completed. In addition, the application will not be loaded into the memory, but will only load the part that is really necessary for the current task. You can think that a Web application has only one instantaneous life cycle. Only the running environment, that is, the Web server, is running continuously. In fact, there will be some flexible policies, such as Session and data serialization, to help maintain data between the lifetime of the application, to imitate stateful operations, such as some frameworks, such as ASP. NET WebForms or JSP is doing this, but after all, these are all technical skills that are irrelevant to the issues discussed in this article. We focus on common Web applications and the process of processing requests. These Web applications only have a very short running status.

Many technologies have proved useful for developing local applications. The object-oriented method can be used to construct a problem environment to help reduce the complexity of the problem. Some design patterns can reflect an efficient and elegant design scheme. The layered architecture separates code responsibilities and minimizes the dependencies between layers. These are all typical best solutions that have been fully proven during local application development.

However, the use of these technical solutions in Web applications is a different situation. We actively use object-oriented methods to define our business models. We adopt various design models to implement a layered architecture. These help improve code quality, increase reusability, and organize applications into various conceptual modules. These are all very effective and are our most commonly used technical routes. But even so, I can't help but remind you that these things seem redundant and have the feeling of cannon hitting mosquitoes. From time to time, I will stare at these exquisite and well-thought-out codes. an uninspired idea will attack my mind: Why don't I just remove them all and simply do what I want to do?

What is direct? Think about a typical processing method for an application to process a request. What happened in the main step? The application receives user input, verifies it, converts it to a format related to the business field, and transfers it to an SQL statement to keep it in the database. What happened below? The program reads some data from the database and formats the information so that it can be recognized by users and returned to users in HTML format. That's it. This is what most Web applications do behind the scenes. There are no special objects in their runtime. They send and receive messages and intelligently interact with each other to implement high-level behavior. No, it's just that some data travels between the user and the database, sends it out, and returns it. Is a data stream. The program code implementing these tasks is essentially like a functional program, regardless of the style they are constructed.

This topic Is functional programming relevant to web development? One eloquent user wrote:

"Functional programming is very compatible with Web application development. The Web application receives an HTTP request and generates an HTML response. This should be regarded as a functional function from the request to the page ."

And I want to add the following. The code that implements these functions essentially reflects the functional style. We do not use real objects to store application states in the memory and use them to implement application logic operations. We use databases to store application states, the entire code is basically a huge, complex functional code that manages specific data streams: databases or users.

What can we get from these discussions? It is not always good to force the use of an object-oriented style and use a complex architecture for Web applications. You may not be able to obtain valuable benefits from this architecture, but from the perspective of performance and future maintenance, they can make your applications too complex and inefficient. We must address the advantages and disadvantages of using a certain method for each project.

When a programmer writes a Web application and suddenly shows a functional programming style Mark in the code, do not criticize or laugh at it immediately. Maybe he did this specially. Perhaps this is a keen perception that Web programming itself is a subconscious manifestation of natural functional programming.

[English source]: Web programming is functional programming