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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- August 2015 Issue of Linux Journal: Programming
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development