Portability and Power with the F Programming Language
With the F programming language, the authors combine over forty years of language-design committee experience to create the world's most portable, yet efficient, powerful, yet simple programming language. The recent attention commanded by the portability and power of Java is well-timed, as we show in F that efficiency and readability need not be made victims of cross-platform development.
Before diving into the F programming language definition, this article begins with some biased-but-almost-factual opinions of the authors. We admit it—we are not fans of C and C++.
Listing a few facts and myths about programming languages will help set the stage for the discussion of F. These opinions may communicate some of the ideas behind the F programming language design, allowing one to better understand the motivations of the authors and thus the language.
Fact 1: Programs are read more often than written. From your first programming assignment throughout your professional career, characters are entered once, following some sort of syntax and logic, and read and reread anywhere from twice to hundreds to thousands of times. Programs that cannot be read are simply poor programs.
Myth 1: Abbrev.R++ abbreviations are good. A programming language with the overall design of abbrev.R++ are quite popular among thinking/creating/coding/debugging speedsters. Afterall, most programmers learned how to program before learning how to type. Abbreviations, however, ranging from a “}” instead of the word “end”, “int” instead of “integer” and i++ or ++i instead of i=i+1 only add pieces to an already complicated puzzle. As with a piece of abstract art, one day someone may look at your code and ask, “That's nice, but what is it?”
Fact 2: Educational languages are dead or dying. As some instructors around the world are searching for a suitable replacement for Pascal, the majority are going-with-the-professional-flow and switching from Pascal to C, C++ or Java for introductory programming courses. There is no telling where computer science would be today if a whole generation of programmers who were brought up on Pascal in the '70s and '80s were presented with the sink-or-swim situation of C++ or Java as a beginning programming language. If Pascal did not exist, the odds are that there would be fewer of us reading this article (if it or the magazine even existed). Surely, a major factor in the rapid evolution of computer science was the once nurturing environment presented by Pascal.
Myth 2: A modern educational replacement for Pascal offers no advantages to the potential professional programmer. Many professionals, particularly those working on large projects, benefit from the advantages of the strict style enforcement that a small programming language offers. A small language can also offer reliable tools (compilers, debuggers, profilers), reliable customer support, reliable error messages and reliable references (textbooks and on-line documentation). As F is a language based on existing practice, professionals can make use of the large amount of existing debugged code.
Fact 3: Choosing the wrong implementation programming language affects the overall design, portability and maintainability of large projects. Many companies have been dealt an expensive blow attempting to keep up with a fast-moving multi-platformed industry with slow-moving software. Whether the software is being enhanced with efficiency and new features or being ported to the latest hardware, a poor choice for the original programming language can result in a serious loss of company resources. Until feeling the headache, it appeared that C was an appropriate, powerful and portable choice. In the early '90s, C++ promised more power and possibly safer features. Today, Java proves safer and portable, but sacrifices efficiency.
Myth 3: The software crisis has been solved. With no solution to the software crisis in sight, focus has been shifted towards “market-driven” distractions like the hot,new programming language filled with more promises than an election-year politician. Meanwhile, most large software projects are still written in C and continue to be delivered late, under-functioned or unstable. As long as a smaller and simpler language does not sacrifice power, it is time for programmers and their management to wake up to the possibility of shipping stable, complete software on schedule. This starts with the decision of an appropriate programming language. An appropriate choice does not emphasize the potential salary of the programmer leading the project, but rather:
C: Do we need to access system information, trading off portability?
C++: Do we need objects and run time binding as well as accessing system information, trading off readability and portability?
Java: Do we need objects, run time binding and portability, trading off efficiency?
F: Do we need portability, efficiency and maintainability trading off access to system information (unless calling C from F) and run time binding? Fact 4: Most statements in most programming languages fit on one line. In the average program, a minority of the statements are split across many lines. Requiring a semicolon at the end of every statement means requiring a semicolon at the end of almost every line. Myth 4: Semicolons are a fact of life. Given that the end of a line is most often the end of a statement, the trivial programming language design decision is to use a special character in the rarer case of needing more than one line for a statement. Requiring a semicolon at the end of a statement is tedious and error prone. Languages requiring a semicolon ought to be required to present a nice error message when the semicolon is forgotten. In F, the end of line is the end of statement. If a statement requires more than one line, an ampersand (“&”) is used at the end of a line.
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
|NVMe over Fabrics Support Coming to the Linux 4.8 Kernel||Aug 22, 2016|
|What I Wish I’d Known When I Was an Embedded Linux Newbie||Aug 18, 2016|
|Pandas||Aug 17, 2016|
- Happy Birthday Linux
- ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs
- Updates from LinuxCon and ContainerCon, Toronto, August 2016
- New Version of GParted
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- NVMe over Fabrics Support Coming to the Linux 4.8 Kernel
- Tor 0.2.8.6 Is Released
- All about printf
- Blender for Visual Effects
- A New Project for Linux at 25
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide