About F # for Architects
This article grew out of a report made by Chris Smith, one of the F # developers at the DevLink conference. In general, it is of an overview nature, but despite this, and the fact that the efforts of shwars , mezastel and partly your humble servant F # have repeatedly flashed on Habré, I think that this programming language has not yet become so obvious to everyone that this article is completely lost meaning. Moreover, here Chris is trying to answer the main question, which, I think, torments everyone who has ever heard of F #. Where does it apply? It turned out he or not - you judge. I hope after reading you at least something about all this will become clearer. If so, I will consider my mission overfulfilled :)
PS The first translation, so do not blame me for some possible bugs.
After the appearance of F #, of course, there are a lot of emotions around it, but the question that most people take is why me? I think we can assume that F # is something good, because otherwise Microsoft wouldn’t have spent so much time and effort to put it in a new Visual Studio 2010. [Note. trans. - a weak argument :)]
Therefore, below we will try to ignore the many emotional expressions that bore our conversations about F # and look the facts in the eye. I'm not going to convince you to start programming in F #, but instead I will say what the language is good for and let you decide for yourself whether it is worth your attention.
If you are programming in C # or VB.NET, and at the same time are immensely happy, then most likely you have no reason to learn F #. Just stay happy. ;) But if you occasionally have to contend with your own .NET code, then perhaps F # is just what you were waiting for.
')
There are a lot of rumors about F #. Here are some of them.
Let us draw a line under the above: you have to understand what F # is and if its use makes your work more efficient, then use it. If not, use what you already know.
Of course, it is very easy to get bogged down in the whole variety of details of a new programming language.
The only thing I ask you to remember about F # as a whole is that it is fascinating to program on it. F # breaks down many of the barriers associated with programming and allows you to concentrate on writing the code you need.
It is important to note that F # supports almost all the features that C # has. Therefore, you can use it without fear of the principle "all or nothing." You do not need to throw away the existing code and translate everything to F #. In general, we expect that F # code will be mainly used as class libraries integrated into a large software product. Perhaps some components of the database server will be written in F #, while the rest of your code will remain in C # / PHP / Smoke Signals / anything.
The ability to seamlessly interact with .NET opens up many possibilities for F #. You can not only use the strengths of existing tools, such as debugger VS, IntelliSense, but also other .NET platforms, for example, use XNA to run the F # code on the XBox, or Silverlight to run it on the network. This synergy is probably the main reason why F # is given much more attention than to earlier programming languages ​​like OCaml. OCaml is great, but does it come with a world-class debugger, visualization libraries, and an ecosystem formed by the developer community?
But still, why learn this new language?
Let's start with the fact that we consider some terms related to F #.
Functional programming has been known since the 50s (LISP) - so why is it so important now? Many will say that things like immutability help write multi-threaded programs, which in my opinion is not so important. Because if you want to seriously engage in multi-threaded programming, there are PLs created specifically for doing this and only this.
The main advantage of functional programming lies in what is called programming in the small .
What determines the current state of affairs in software development? - OOP. The main way in which we solve the problem of converting an algorithm into a code is breaking it up into objects, effectively modeling the subject area with the help of classes and their behavior. This is programming in general . The process of abstraction works fine for modeling large systems and dividing them into smaller and smaller levels, but ultimately you will hit the wall.
What about the bodies of the methods? Real code that is enclosed in classes? This is programming in small. The problem with OOP is that when you write code of an algorithmic type, it does not make sense to create classes and interfaces. When you program in the small, all you really do is transform the data and make calculations.
Imagine that the PLO is a baseball trap. It is well suited to catch a baseball, but not nearly as comfortable as catching a football. For this you need fingers to move. Functional programming and describes the essence of programming in the small. It focuses on data manipulation, which needs to be implemented without problems with classes and a given type hierarchy.
The first area in which F # is really unsurpassed is technical and quantitative programming, i.e. in complex mathematical calculations.
Simulation is one of the areas where F # fits well. Imagine that you are writing some kind of physical simulator, or are trying to simulate some realistic situation. In F #, you can neatly write the functions you need without having to pull code abstractions into real-world processes.
Another aspect of simulations that makes F # a good choice for them is the unit of measurement . You can encode units of measure, such as "feet" or "meters per second" into a valid F # type system. After that, you will receive a compiler warning if you try to add acceleration to speed. This allows you to protect yourself from a number of bugs.
Some of the very first firms to use F # were in finance computing. These firms have large databases for automated trading on stock exchanges, risk calculations, etc. (Just the sort of computerized finance that caused the current global economic crisis :)) F # provides these investment companies not only with a way to express their financial models in a simpler and more declarative way, but also integrate with the rest of their applications through .NET interaction. (For example, sending intensive computations to several machines via a COM service, and stuff like that)
Finally, F # does a good job with data mining tasks. For example, imagine that you are trying to extract some customer information in order to recognize trends. In F #, you can simply work with your data in the F # Interactive Window, and there is no need to clutter up your machine with dozens of one-time projects. Also, using a concise F # programming model, the cost of an error — re-factoring or rescheduling your approach — is noticeably reduced.
The next item is the PLO , which means the blurring of the border between PL and natural languages. (For more information about using F # in YAOP, see Chris's article. )
If you want to be advanced in domain-specific languages, why not go ahead and write your own parser? And in the F # PowerPack library there are FSLex and FSYacc, two great tools for creating parsers. In fact, the F # compiler parser was created using FSLex and FSYacc.
Another great example of LOPs is the use of computational expressions that are in F #. This is a powerful language feature that allows you to write normal F # code and customize the way it is executed. For example, imagine that you want to write some F # code for interacting with a robot on Mars. Instead of writing tons of pattern code to try again to send every command you send to an all-terrain vehicle — for example, in the case of cosmic obstacles or Martian rebellions — you can write a computational expression (so-called F # Workflow) to automatically restart any F # code times until a certain point, or until it succeeds.
(This is quite a complex topic, which actually need to devote more than one article)
Another area in which F # is excellent is the creation of internal domain-specific languages ​​(DSL, mini programming languages ​​embedded in your code). Marked unions make the process of creating abstract syntactic trees (or any other tree-like structures) very simple.
Finally, there is Expression Trees in F #, as in C # and VB.NET. This allows you to get a “compiler-generated” form of F # code that, together with the appropriate libraries, can allow you to give the program execution to other platforms. For example, on a SQL server or graphics processor for your video card.
F # is also good at multi-threaded programming, to be more precise: in parallel, asynchronous, concurrent and responsive programming domains. F # does not parallelize your code automatically, and does not have any built-in support for parallel primitives. Instead, it has several features that make parallel programming easier. But none of them is a silver bullet.
In F #, as in most other FNPs, data is immutable by default. Therefore, if your program lies in the pure functional paradigm, you will not have any problems with races when performing multiple streams, since there is no divided changeable state for the two competing streams.
Generally speaking, this functionality applies not only to F #, but to the whole .NET. The long way to make writing parallel programs easier was crowned with the introduction of the Parallel Extensions (PFX) library into the fourth version of .NET. Although PFX provides many excellent features to the .NET platform, there are two things that I particularly liked.
Task Parallel Library (TPL) is a set of classes for abstracting the process of placing program “tasks”. With the help of TPL, you can forget about the need to manually post tasks and manage flows. Instead you can trust TPL. He will do it for you, he will also adjust the number of running threads, to be sure that you will not overload the system with parallel tasks.
Another, and perhaps even more remarkable, part of PFX is Concurrent Data Structures. This is a new set of collection types that are specifically designed to work with high-performance multi-threaded applications. Therefore, instead of controlling all the details of a shared changeable state, you can simply give the opportunity to write to both threads in one of these competitive structures, and all the dirty work with lock-unlocks will no longer concern you.
You may have heard somewhere before that F # makes asynchronous programming very easy - that’s one hundred percent true.
In order to write asynchronous programs on .NET, you need to use Asynchronous Programming Model (APM). This is a template in which you start an asynchronous operation, for example, reading from a file, calling BeginOp (i.e. BeginRead) and sending a callback. When an asynchronous operation completes, a callback is executed in which you must call EndOp (i.e. EndRead)
Although this approach has faithfully served .NET for almost a decade, it’s pretty damn unpleasant to deal with.
The slide above shows the code from the development team at Microsoft Patterns and Practices, and is the recommended way to handle a series of pictures in multi-threaded mode. In any case, it should be noted that there is a lot of code that does not look too simple.
And this is how you can write the same F # program using the F # Asynchronous Workflows library. As I have said many times, F # was not created specifically for writing multi-threaded programs. F # Asynchronous Workflows is just some functionality built into the F # library that makes asynchronous programming very easy. It is enabled via F # Computation Expressions.
In this code, you can see 'let!' and 'do!' F # Asynchronous Workflows performs these operations asynchronously, turning all activity on threads and callbacks behind the scenes.
So, I told you a lot about how great F # is, but let's go back to reality. You do not believe that F # is a solid fairy tale?
F # is not suitable for everything, here are some of these areas.
In F # 1.0, we are not going to provide any code generators. Therefore, you will not be able to use any WYSIWYG editors from WinForms or WPF. If you want to write a presentation layer in F #, you have to, unfortunately, do it all by hand. However, this is not the end of the world due to the FNET .NET involvement. You can simply create your C # UI and call your F # code through the class libraries.
Even though F # allows you to write object-oriented code, this is not the main language paradigm, so writing complex OO code may look a bit strange. F # also supports many functional constructs that do not support C # and VB, such as tagged unions and currying functions. Therefore, if you create an F # library that uncovers "functional" code, it would be wrong if you try to use it in non-functional languages.
The main thing here is to properly encapsulate your F # code, programming in small, when you want to integrate it with a large component, programming in general.
What to do next if you decide that F # is suitable for some part of your application? Should you attend to hiring a group of loose nuclear physicists? Not. I can only repeat myself and shout a loud "NO!" From the bottom of my heart. F # - not only for egg heads! For example, this summer we hired several graduate interns to work on some examples of F #.
Functional programming is essentially nothing complicated, it just considers tasks from a different point of view. The main thing is to be attentive to the statements of your programmers when they learn F #.
Let F # today help you write more productive code, but the question is, how easy can you handle it tomorrow? What are the costs of maintaining an F # code in the long run?
One of the main advantages of F # is that it is short. I have already mentioned this before, but I will say it again: when you debug the code, the ability to see all the code relating to the problem on the screen saves you from having to constantly switch the context between different code files.
It can be said that hallucinogenic functional code is more difficult to understand than the more usual imperative. This, of course, is true, but it is also true that first of all you should not write hallucinogenic code. (Just like there is no need for any other programming language). The idiomatic F # code is clear and readable. Of course, you can use many features of the language, such as composition of functions and currying, without complicating the code too much.
In conclusion, I repeat: if you really like to use C # or VB, just use them further. You can benefit from learning F #, as well as learning from any other language, but do not switch to F # if there is no definite reason for it.
But if it seems to you that your language does not allow you to fully express your ideas to you, littering your code with unnecessary syntactic garbage, in which meaning is lost, try F #. In areas related to a large number of computations or data transformations — technical programming, IOP, parallel / asynchronous — you can get substantial benefits.
Writing F # code will not make your programs faster or less resource intensive, as if by magic. All that he does is giving you the opportunity to look at the problem from the other side, from which its solution may turn out more efficient, and simply increases the number of ways to express your ideas.
So, if you haven’t set yourself F #, you can do it right now: fsharp.net
Linux developers can work with F # in Mono. mono-project.com
PS The first translation, so do not blame me for some possible bugs.
After the appearance of F #, of course, there are a lot of emotions around it, but the question that most people take is why me? I think we can assume that F # is something good, because otherwise Microsoft wouldn’t have spent so much time and effort to put it in a new Visual Studio 2010. [Note. trans. - a weak argument :)]
Therefore, below we will try to ignore the many emotional expressions that bore our conversations about F # and look the facts in the eye. I'm not going to convince you to start programming in F #, but instead I will say what the language is good for and let you decide for yourself whether it is worth your attention.
If you are programming in C # or VB.NET, and at the same time are immensely happy, then most likely you have no reason to learn F #. Just stay happy. ;) But if you occasionally have to contend with your own .NET code, then perhaps F # is just what you were waiting for.
')
Gossip
There are a lot of rumors about F #. Here are some of them.
- The code you are currently writing in C # will become obsolete tomorrow. - Not true. F # is not going to replace C # or VB. F # is just different, so some things on it are easier to do, and some are more difficult. The point is that with F #, you have a choice. And below we will try to identify some of the situations where F # may be preferable to C #.
- In F #, you can parallelize code for free. - Not true. Although F # (and other FNPs) make it easier to parallelize code, it does not do it for nothing. Generally speaking, you can write the same locks or races on F # as on C #. The advantage of F # is that you must first obviously aim your gun at the foot. (Approx. Translation: an allusion to the old programmer's joke about how the task is implemented in different languages to shoot yourself in the leg .)
- For functional programming, the future is not true. Functional programming languages ​​are nowadays becoming objects of increasing attention - Erlang, Scala, Nemerle, Haskell, etc. Nevertheless, the key ideas of functional programming appeared a long time ago. And I do not think that functional programming will become the main and only paradigm to which all will switch. Rather, in my opinion, this is a good way to solve a specific class of problems. F # is a hybrid language, and it allows you to write code in the paradigm that best suits the current task.
- F # programmers are smarter and look better than others. - True. Absolute.
- You should rewrite all your ASP.NET applications in F #. - Not true. In the main DevLink report, Josh Holmes especially stressed that this is a bad idea. Not that the F # + ASP.NET bundle itself was a bad idea, but the desire to use new technologies just to use new technologies makes things harder than they should be.
Let us draw a line under the above: you have to understand what F # is and if its use makes your work more efficient, then use it. If not, use what you already know.
Tongue
- As I noted above, F # is a multi-paradigm programming language. You can write functional, imperative, and object-oriented code in it. This allows you to be more pragmatic, instead of trying to push any task that you have into the Procrustean bed of classes and interfaces.
- F # uses type inference, which leads to more concise programs. Think about how much time you spend adding type signatures, semicolons, curly braces in your favorite PL. All this information is just crutches that make it easier to write a compiler. Why not write the code you want and let the compiler calculate the rest? You will see later why I consider the conciseness of F # to be its main strength.
- F # is a .NET programming language. It is compiled into IL in the same working cycle as C # with VB and will easily work with already existing .NET code.
Instruments
- F # is included in the standard set of Visual Studio 2010, although present now, as a plug-in for VS2008.
- It has an interactive programming environment ( REPL ) for both Ruby and Python, called F # Interactive Window.
Of course, it is very easy to get bogged down in the whole variety of details of a new programming language.
The only thing I ask you to remember about F # as a whole is that it is fascinating to program on it. F # breaks down many of the barriers associated with programming and allows you to concentrate on writing the code you need.
It is important to note that F # supports almost all the features that C # has. Therefore, you can use it without fear of the principle "all or nothing." You do not need to throw away the existing code and translate everything to F #. In general, we expect that F # code will be mainly used as class libraries integrated into a large software product. Perhaps some components of the database server will be written in F #, while the rest of your code will remain in C # / PHP / Smoke Signals / anything.
The ability to seamlessly interact with .NET opens up many possibilities for F #. You can not only use the strengths of existing tools, such as debugger VS, IntelliSense, but also other .NET platforms, for example, use XNA to run the F # code on the XBox, or Silverlight to run it on the network. This synergy is probably the main reason why F # is given much more attention than to earlier programming languages ​​like OCaml. OCaml is great, but does it come with a world-class debugger, visualization libraries, and an ecosystem formed by the developer community?
But still, why learn this new language?
Let's start with the fact that we consider some terms related to F #.
- Statically typed. F # is a statically typed language, unlike, for example, dynamically typed Ruby. This means that the type information is known at compile time. Therefore, although you can not do some things, such as monkey patches , but the code is executed much faster and you can learn about most of the errors at the compilation stage.
- Laconic. In addition to deducing types, F # also uses significant spaces. If you shift the lines under the if-construction a few spaces to the right, the compiler will regard them as the body of an operator. This saves you from having to clog your code with curly braces and saves you vertical space. Less code on the page means that you can see most of the program at the same time, and less to switch the context by viewing the code. It may not sound too big, but in fact it will be a great help to your effectiveness.
- Extensible. It's not about data centers and web servers, but about the fact that if you apply holistic principles for software development to your F # code, you can write enterprise level applications on it. (Simply put, F # is not just a language for one-time utilities.)
- Investigated. In F #, you do not need to refer to the design to understand how everything works. You can quickly prototype F # solutions, as well as experiment with algorithms and approaches using the F # Interactive Window. Relying on the laconic nature of F #, you will not write a lot of code to experiment with your programs.
- Libraries. F # comes with its own library for writing functional code and much more.
Functional vs Object Oriented
Functional programming has been known since the 50s (LISP) - so why is it so important now? Many will say that things like immutability help write multi-threaded programs, which in my opinion is not so important. Because if you want to seriously engage in multi-threaded programming, there are PLs created specifically for doing this and only this.
The main advantage of functional programming lies in what is called programming in the small .
What determines the current state of affairs in software development? - OOP. The main way in which we solve the problem of converting an algorithm into a code is breaking it up into objects, effectively modeling the subject area with the help of classes and their behavior. This is programming in general . The process of abstraction works fine for modeling large systems and dividing them into smaller and smaller levels, but ultimately you will hit the wall.
What about the bodies of the methods? Real code that is enclosed in classes? This is programming in small. The problem with OOP is that when you write code of an algorithmic type, it does not make sense to create classes and interfaces. When you program in the small, all you really do is transform the data and make calculations.
Imagine that the PLO is a baseball trap. It is well suited to catch a baseball, but not nearly as comfortable as catching a football. For this you need fingers to move. Functional programming and describes the essence of programming in the small. It focuses on data manipulation, which needs to be implemented without problems with classes and a given type hierarchy.
Areas of use
The first area in which F # is really unsurpassed is technical and quantitative programming, i.e. in complex mathematical calculations.
Simulation
Simulation is one of the areas where F # fits well. Imagine that you are writing some kind of physical simulator, or are trying to simulate some realistic situation. In F #, you can neatly write the functions you need without having to pull code abstractions into real-world processes.
Another aspect of simulations that makes F # a good choice for them is the unit of measurement . You can encode units of measure, such as "feet" or "meters per second" into a valid F # type system. After that, you will receive a compiler warning if you try to add acceleration to speed. This allows you to protect yourself from a number of bugs.
Computational Finance
Some of the very first firms to use F # were in finance computing. These firms have large databases for automated trading on stock exchanges, risk calculations, etc. (Just the sort of computerized finance that caused the current global economic crisis :)) F # provides these investment companies not only with a way to express their financial models in a simpler and more declarative way, but also integrate with the rest of their applications through .NET interaction. (For example, sending intensive computations to several machines via a COM service, and stuff like that)
Large data processing
Finally, F # does a good job with data mining tasks. For example, imagine that you are trying to extract some customer information in order to recognize trends. In F #, you can simply work with your data in the F # Interactive Window, and there is no need to clutter up your machine with dozens of one-time projects. Also, using a concise F # programming model, the cost of an error — re-factoring or rescheduling your approach — is noticeably reduced.
Language-oriented programming
The next item is the PLO , which means the blurring of the border between PL and natural languages. (For more information about using F # in YAOP, see Chris's article. )
Writing parsers
If you want to be advanced in domain-specific languages, why not go ahead and write your own parser? And in the F # PowerPack library there are FSLex and FSYacc, two great tools for creating parsers. In fact, the F # compiler parser was created using FSLex and FSYacc.
Extensible F # code
Another great example of LOPs is the use of computational expressions that are in F #. This is a powerful language feature that allows you to write normal F # code and customize the way it is executed. For example, imagine that you want to write some F # code for interacting with a robot on Mars. Instead of writing tons of pattern code to try again to send every command you send to an all-terrain vehicle — for example, in the case of cosmic obstacles or Martian rebellions — you can write a computational expression (so-called F # Workflow) to automatically restart any F # code times until a certain point, or until it succeeds.
(This is quite a complex topic, which actually need to devote more than one article)
Creating new languages
Another area in which F # is excellent is the creation of internal domain-specific languages ​​(DSL, mini programming languages ​​embedded in your code). Marked unions make the process of creating abstract syntactic trees (or any other tree-like structures) very simple.
Expression Trees
Finally, there is Expression Trees in F #, as in C # and VB.NET. This allows you to get a “compiler-generated” form of F # code that, together with the appropriate libraries, can allow you to give the program execution to other platforms. For example, on a SQL server or graphics processor for your video card.
Multithreaded programming
F # is also good at multi-threaded programming, to be more precise: in parallel, asynchronous, concurrent and responsive programming domains. F # does not parallelize your code automatically, and does not have any built-in support for parallel primitives. Instead, it has several features that make parallel programming easier. But none of them is a silver bullet.
Immutability by default.
In F #, as in most other FNPs, data is immutable by default. Therefore, if your program lies in the pure functional paradigm, you will not have any problems with races when performing multiple streams, since there is no divided changeable state for the two competing streams.
Parallel Extensions in .NET
Generally speaking, this functionality applies not only to F #, but to the whole .NET. The long way to make writing parallel programs easier was crowned with the introduction of the Parallel Extensions (PFX) library into the fourth version of .NET. Although PFX provides many excellent features to the .NET platform, there are two things that I particularly liked.
Task Parallel Library (TPL) is a set of classes for abstracting the process of placing program “tasks”. With the help of TPL, you can forget about the need to manually post tasks and manage flows. Instead you can trust TPL. He will do it for you, he will also adjust the number of running threads, to be sure that you will not overload the system with parallel tasks.
Another, and perhaps even more remarkable, part of PFX is Concurrent Data Structures. This is a new set of collection types that are specifically designed to work with high-performance multi-threaded applications. Therefore, instead of controlling all the details of a shared changeable state, you can simply give the opportunity to write to both threads in one of these competitive structures, and all the dirty work with lock-unlocks will no longer concern you.
Asynchronous programming
( msdn.microsoft.com/en-us/library/ms978405.aspx details)You may have heard somewhere before that F # makes asynchronous programming very easy - that’s one hundred percent true.
In order to write asynchronous programs on .NET, you need to use Asynchronous Programming Model (APM). This is a template in which you start an asynchronous operation, for example, reading from a file, calling BeginOp (i.e. BeginRead) and sending a callback. When an asynchronous operation completes, a callback is executed in which you must call EndOp (i.e. EndRead)
Although this approach has faithfully served .NET for almost a decade, it’s pretty damn unpleasant to deal with.
- Passing states via callback is tedious and provoking errors.
- It’s not easy for you to catch and handle exceptions if your code is spread among the myriad callbacks.
- and. etc.
The slide above shows the code from the development team at Microsoft Patterns and Practices, and is the recommended way to handle a series of pictures in multi-threaded mode. In any case, it should be noted that there is a lot of code that does not look too simple.
And this is how you can write the same F # program using the F # Asynchronous Workflows library. As I have said many times, F # was not created specifically for writing multi-threaded programs. F # Asynchronous Workflows is just some functionality built into the F # library that makes asynchronous programming very easy. It is enabled via F # Computation Expressions.
In this code, you can see 'let!' and 'do!' F # Asynchronous Workflows performs these operations asynchronously, turning all activity on threads and callbacks behind the scenes.
disadvantages
So, I told you a lot about how great F # is, but let's go back to reality. You do not believe that F # is a solid fairy tale?
F # is not suitable for everything, here are some of these areas.
Presentation layer
In F # 1.0, we are not going to provide any code generators. Therefore, you will not be able to use any WYSIWYG editors from WinForms or WPF. If you want to write a presentation layer in F #, you have to, unfortunately, do it all by hand. However, this is not the end of the world due to the FNET .NET involvement. You can simply create your C # UI and call your F # code through the class libraries.
Object Oriented Hierarchies
Even though F # allows you to write object-oriented code, this is not the main language paradigm, so writing complex OO code may look a bit strange. F # also supports many functional constructs that do not support C # and VB, such as tagged unions and currying functions. Therefore, if you create an F # library that uncovers "functional" code, it would be wrong if you try to use it in non-functional languages.
The main thing here is to properly encapsulate your F # code, programming in small, when you want to integrate it with a large component, programming in general.
What to do next if you decide that F # is suitable for some part of your application? Should you attend to hiring a group of loose nuclear physicists? Not. I can only repeat myself and shout a loud "NO!" From the bottom of my heart. F # - not only for egg heads! For example, this summer we hired several graduate interns to work on some examples of F #.
Functional programming is essentially nothing complicated, it just considers tasks from a different point of view. The main thing is to be attentive to the statements of your programmers when they learn F #.
- "It is almost the same as C # . " This means that they do not use it correctly. The whole point of F # is that it offers a different way of thinking about programming, and in this, a different approach is more effective. If you write a C # code in F #, you won’t win anything.
- "F # is too simple for real-world tasks . " Although F # is easy to learn, you can achieve quite a lot even if you write simple functions.
- "Functional programming makes my brain . " This means that you are on the right track. Studying F # opens up other approaches to solving problems.
Support
Let F # today help you write more productive code, but the question is, how easy can you handle it tomorrow? What are the costs of maintaining an F # code in the long run?
One of the main advantages of F # is that it is short. I have already mentioned this before, but I will say it again: when you debug the code, the ability to see all the code relating to the problem on the screen saves you from having to constantly switch the context between different code files.
It can be said that hallucinogenic functional code is more difficult to understand than the more usual imperative. This, of course, is true, but it is also true that first of all you should not write hallucinogenic code. (Just like there is no need for any other programming language). The idiomatic F # code is clear and readable. Of course, you can use many features of the language, such as composition of functions and currying, without complicating the code too much.
Conclusion
In conclusion, I repeat: if you really like to use C # or VB, just use them further. You can benefit from learning F #, as well as learning from any other language, but do not switch to F # if there is no definite reason for it.
But if it seems to you that your language does not allow you to fully express your ideas to you, littering your code with unnecessary syntactic garbage, in which meaning is lost, try F #. In areas related to a large number of computations or data transformations — technical programming, IOP, parallel / asynchronous — you can get substantial benefits.
Writing F # code will not make your programs faster or less resource intensive, as if by magic. All that he does is giving you the opportunity to look at the problem from the other side, from which its solution may turn out more efficient, and simply increases the number of ways to express your ideas.
So, if you haven’t set yourself F #, you can do it right now: fsharp.net
Linux developers can work with F # in Mono. mono-project.com
Source: https://habr.com/ru/post/71656/
All Articles