Home > Uncategorized > Fortran, Forth, Frink and Flow

Fortran, Forth, Frink and Flow

F is for Fortran, Forth, Frink and Flow.

Fortran is a member of the triumvirate of founding major languages. Its continuing success is due to it doing a good job addressing important application areas (i.e., big engineering and scientific number crunching problems) and the availability of high quality compilers (non-software engineers will pay for good tools and big science problems attract lots of government funding). Computer science types may turn their noses up at Fortran, but they are in the fashion business (which is why Algol 60 died out) and not interested in solving big real-world problems. For many years Fortran compilers reliably generated faster code than C compilers because lots of customers will willing to pay for high quality (C compilers assumed that optimization was the programmer’s responsibility) and because Fortran’s lack of pointer types made it much easier to figure out what code was doing. These days C compilers have been around long enough that high-end optimizations have trickled into them and they also have enough processing power and main memory to figure out what those pointers are getting up to.

Forth and BASIC were the minimalist languages of their day (and Forth still is in some niches). Forth was the techi’s language (who else would be content to write code using reverse Polish) that allowed developers to get that bit closer to the bare metal and talk technical stuff about threaded code. Perhaps the reason Forth has lost the general appeal it once had is because its core users have embraced respectability (e.g., creating a language standard and boasting about the availability of ‘proper’ compilers); returning Forth to its roots of bare metal, threaded code, hell-raising might bring back the following it once had.

Frink supports dimensional analysis of source code, something I am a big fan of (this kind of analysis is a step up from traditional strong type checking). Other languages designed, in a bygone age, to support dimension checking have disappeared, as have proposals to extend popular languages.

Flow adds gradual typing to Javascript; it is from Facebook who seem to be making a habit of this sort of thing, and I hope they succeed. A consequence of OO’s success is that most developers now think of types purely in terms of a mechanism for matching calls to the appropriate method. The idea of intentionally creating type information that is intended to fail to match, as a means of detecting coding mistakes, has been lost to a generation of developers. I would like to predict that languages supporting strong static typing are going to make a big comeback (once word starts to spread about the time saving benefits of static type checking), but things did not turn out that way last time such languages were in fashion.

Categories: Uncategorized Tags:
  1. December 6, 2014 07:34 | #1

    I think the most well-known programming language with built-in support for units of measure is F# – see http://msdn.microsoft.com/en-us/library/dd233243.aspx

    It comes from work by Andrew Kennedy at Cambridge – http://research.microsoft.com/en-us/um/people/akenn/units/index.html

  2. December 6, 2014 08:21 | #2

    @Tony Finch
    Yes, Kennedy’s page is a greatresource on the topic of units of measurement. F# is certainly much more well known than Frink which is more of a domain specific language.

  3. December 16, 2014 09:32 | #3

    think it’s amazing that more languages don’t allow you to track units of measure through calculations. But I’m also amazed that most languages don’t have rational numbers and silently turn expressions like “1/2” into 0. Most of us would have failed elementary-school math with that behavior. 🙂

    Disclosure: I’m the author of Frink. One of the F# developers and I spoke at the same conference. After my presentation, he came up to me and said something like, “I said that F# tracked units of measure, but I should say that it’s really just an afterthought.” He noted that F# doesn’t track units of measure the same way Frink does. It’s important to know that F# *erases all knowledge* of units of measure at compile-time, and just turns any dimensioned quantities into opaque dimensionless numbers, so at runtime you’re not able to query nor validate the dimensions of values in your program, and you can’t, say, read a data file with dimensioned data, nor take input with dimensions from a user and validate it properly.

    Frink, on the other hand, tracks units of measure through all calculations, and allows validation of units of measure at runtime.

    For example, a Frink program can easily take input from a user and handle its units of measure correctly:

    mass = eval[input[“How tall are you?”]]

    and the user can enter any mathematical expression like:

    185 cm

    or

    6 feet + 1 inch

    or

    1 meter + 2.3 feet

    and Frink will handle even the mixed systems of units correctly.

    Mathematica and “Wolfram Language” also have some dimensional analysis, but they have nonstandard orthography and are happy to let you do things like:

    1 Foot + 1 Milli Second

    (the odd capitalization and spacing are required) and will happily continue on forever with the dimensional misanalysis, and will only correct you when you finally try to convert them to a specific unit of measure.

    In conclusion, I will admit that Frink is a domain-specific language if we admit that the domain is our universe or any computable universe. 🙂

  1. No trackbacks yet.