Recent searches

No recent searches

Search options

Only available when logged in.
101010.pl is one of the many independent Mastodon servers you can use to participate in the fediverse.
101010.pl czyli najstarszy polski serwer Mastodon. Posiadamy wpisy do 2048 znaków.

Administered by:

Server stats:

504
active users

101010.pl: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.0-beta.2

#fortran

3 posts3 participants0 posts today
Matthias Noback

New #Fortran post: "Enumeration, part 2" matthiasnoback.nl/2025/06/fort

We increase type safety by narrowing the integer level argument to a derived type argument. By introducing a factory type for log levels we are able to separate responsibilities. Finally we allow level comparisons using operator overloading.

Matthias Noback · Fortran: Enumeration, part 2Type safety, a log level factory, and operator overloading
Matthias Noback

New #Fortran post: "Fortran: Enumeration, part 1" matthiasnoback.nl/2025/06/fort

We are refactoring the integer parameters for the various log levels that we want to support. We want to accomplish type-safety and ease-of-use (pun intended).

Matthias Noback · Fortran: Enumeration, part 1In the post about decoration we declared log levels as follows: module logging_base ! ... integer, parameter, public :: LOG_DEBUG = 0 integer, parameter, public :: LOG_INFO = 1 integer, parameter, public :: LOG_WARN = 2 integer, parameter, public :: LOG_ERROR = 3 integer, parameter, public :: LOG_FATAL = 4 ! ... end module logging_base This is somewhat useful, but requires a dedicated only mention when importing each of these constants, which isn’t very nice: program main use logging_base, only: log, LOG_DEBUG, LOG_WARN ! ... call log('A debug message', LOG_DEBUG) ! ... call log('A warning', LOG_WARN) end program main Although we could live with that, the bigger issue remains: this is not a type-safe solution. Any integer may be passed as an argument for level, and the compiler wouldn’t warn us. For example:
Matthias Noback

New #Fortran post: "Module Design" matthiasnoback.nl/2025/06/fort

We look into splitting an existing module into smaller modules. We then put a façade module in front of the smaller modules, so users only have to deal with a simple programming interface. Finally we fix compilation cascade issues by introducing the concept of a submodule.

Matthias Noback · Fortran: Module DesignFortran projects are famous for their large modules. Actually, we may also find very large files in legacy projects written in other languages, like Java, PHP, etc. These projects sometimes have files with thousands of lines of code. Fortran projects suffer more from large files I’d say, because: IDE support is not great. It’s often still hard to navigate to definitions or usages. There isn’t any support for automated refactorings, like extract function, move function, add parameter, etc. You often can’t get a clear overview of the structure/outline of a file. There are no strict indentation rules, making it easy to create a complete mess. Not everyone uses code formatting tools. Code formatting tools that exist and are used, aren’t always very good or easily configurable. Fortran code can be hard to read, partially because a lack of curly braces. It’s hard to visually recognize blocks of code. Another reason is that commonly there’s no distinction in letter casing between type names, function names, variable names, etc. Other languages may use CamelCase for types, CAPS for constants, pascalCase for methods, snake_case for functions, etc. In Fortran code, it’s all snake_case. If there’s anything we can do to make Fortran code easier to deal with, it’s to split the code into smaller parts. We need to have many more modules, each with distinct topics and concerns, so we can get a quick overview of the application’s domain and capabilities. Additionally, this will help us find the right place when we want to make changes to the code.
Matthias Noback

New #Fortran post: Service Composition, part 2: Decoration matthiasnoback.nl/2025/06/fort

In this post we explore another way of composing abstractions, which is called decoration. We prefix existing log messages with a timestamp and implement optional delegation based on a configured log level.

Matthias Noback · Fortran: Service Composition, part 2: DecorationIn the previous post we saw how to use an abstraction to compose an aggregation of services of that same abstraction. There we simply delegated a call, adding no specific behavior. But we might as well add some new behavior before or after delegating the call. As an example, let’s try to implement a new feature in the logging module: we want to add a timestamp in front of each message, so the output becomes something like this:
Matthias Noback

New #Fortran post "Fortran: Service Composition, part 1: Aggregation" matthiasnoback.nl/2025/06/fort

We are ready to build more features into the logging library, using different styles of composition. First we look at aggregation.

Matthias Noback · Fortran: Service Composition, part 1: AggregationWith our new service abstraction logger_t we are able to easily implement more features for our logger. We can do this without affecting current user code, because their code relies only on the abstraction, never on concrete implementations. A terminal output logger One thing we can do is define a second logger type, one that prints each message to the terminal output (stdout). Being a logger, it should also extend the abstract logger_t type, and provide an implementation for log():
Matthias Noback

New #Fortran post: "Abstract Types and Deferred Procedures" matthiasnoback.nl/2025/06/fort

We define an abstract type with deferred procedures (in OO language: an interface) for the file logger. Introducing an abstract factory allows clients to decouple from specific service types and shows us how polymorphism works.

Matthias Noback · Fortran: Abstract Types and Deferred ProceduresWith the new file_logger_t type we were able to model a logger service as a derived type. Now it’s time to make the service abstract. That is, to leave out the implementation detail that it’s a file logger (not a terminal output logger, etc.). Users should be able to use this abstract service to log any message, to whatever the application has been configured to log to. An abstract derived type Allowing a user to depend on an abstract service requires the use of an abstract type. The user can import this abstract type in their module or program. Meanwhile, the factory function for the abstract logger will actually return the concrete file logger, which extends the abstract logger. For object-oriented programmers this may be a familiar approach, but it’s not a very common Fortran practice. In code it looks as follows:
Matthias Noback

New #Fortran post: "Modeling Services as Derived Types" matthiasnoback.nl/2025/06/fort

Derived types are good for "data objects", but they can also be used for "service objects". We look at a safe refactoring from module state and subroutines to a derived type with a data component and a type-bound procedure.

Matthias Noback · Fortran: Modeling Services as Derived TypesWe’ve seen how to define a derived type to represent a point in 2D space. We were able to add a type-bound procedure to it, and finally to make its components private and define a custom constructor for it. In essence there are two categories of derived types: Derived types that hold some data. Their type-bound procedures are solely dealing with this data, and may produce valuable information with it. The point is an example of such a derived type: we can use its data to make geometrical calculations, or we can combine it together with other points into lines, polygons, etc. This all happens in memory. In typical business applications you would consider entities, value objects and data transfer objects (DTOs) to be in this first category. Derived types that can perform some task that deals with things external to the application, like a file, the terminal, a network connection, etc. Such a type doesn’t hold data inside. It is able to fetch data, or send/store data. In business applications such a type is often called a service. In object-oriented programming, service types usually offer an abstraction. This allows the client to decouple from its specific implementation details. For example, take a logger service; it’s often beneficial for the user that they don’t have to be concerned about where the logs are written to (file, screen, log aggregation server, etc.). The user only wants to call a simple log() function to log something to whatever has been configured at some higher level. Introducing an logger abstraction will take a few posts from here, but it’s good to know that service abstraction is the goal.
Matthias Noback

New #Fortran article: "Private Data Components and Custom Constructors" matthiasnoback.nl/2025/06/fort

We make the data inside the derived type private (encapsulation), offer alternative ways for creating new instances (factory functions), and expose these alternatives as an abstract function.

Matthias Noback · Fortran: Private Data Components and Custom constructorsIn the previous post we have worked on the point_t derived type, turning the module procedure distance into a type-bound procedure: module geometry ! ... type :: point_t real :: x real :: y contains procedure :: distance => point_distance end type point_t contains pure function point_distance(point_1, point_2) result(the_distance) class(point_t), intent(in) :: point_1 ! ... end function point_distance end module geometry Private data components Type-bound procedures can help us tie relevant behaviors (procedures) to derived types. It also allows us to let the derived type keep its data to itself. This is often called data hiding, or encapsulation of state. Nothing outside the module where the derived type is defined will have (read or write) access to its data components. This can be accomplished by adding the attribute private to each data component:
Computer History Museum 🇸🇮

📘 FORTRAN IV Manual (1982), adapted by Rafko Adrinek and published by Iskra Delta! 💖 #FORTRAN was the first widely adopted “standard” programming language, especially popular during the 1960s and 70s — the punch card era. 💾 Back then, it powered massive mainframes, and its legacy still lives on today in modern supercomputer programming! 🚀

Riley S. Faelan

Pondering if I dare to put #Fortran into my CV. :blobcatthinking:

I can do some Fortran, partly because it keeps coming up in all sorts of #retrocomputing contexts, but, even with Ratfor enhancements, I don't consider it a well-designed or pleasant language, and I'm not sure I can see myself working at a place that deals in new Fortran code now that nice, human-friendly languages such as NumPy and APL have been invented. Besides, 21st century Fortran is a really weird language that doesn't even know what it wants to be when it grows up.

*
amen zwa, esq.

The original #LISP had 7 primitives: \(\texttt{cons}\), \(\texttt{car,}\) \(\texttt{cdr}\), \(\texttt{atom}\), \(\texttt{quote}\), \(\texttt{eq}\), and \(\texttt{cond}\). And the original #Smalltalk syntax could fit on a 5×7 card. That meant a novice could learn the syntax in a matter of minutes, and direct all his efforts to learning how properly to wield the power of that Turing-complete language. This was why, in the 1970s and the 1980s, many college freshmen were taught FP in Scheme (a more modern LISP) and many middle school children were taught OO in Smalltalk. These were surely the best "first" #programming languages.

#FORTRAN and #BASIC were simple, too. FORTRAN, the first high-level language, has been in continuous use since the late 1950s by engineers, who are not keyboard warriors. BASIC was invented in the early 1960s for teaching programming to non-STEM students at Dartmouth. It sired a whole generation of self-taught children in the 1980s.

Compare those to C++, Erlang, Python, Haskell, Java, JavaScript, Scala, Rust, Kotlin, and pretty much every language in popular use today. Most consider Python and JavaScript to be the simplest of modern languages. Yet, they are massive, complex languages. No 10-year-old could teach himself those, nor should he.

The original versions of those classic languages cannot be used to solve modern problems. But they should still be taught to youngsters as their first language. Throwing in the kids' faces a modern enterprise language confuses them and discourages them. Consequently, many novices never attain that state of flow, when the joy of programming gushes forth.

#Simplicity is a virtue. Self-motivated learning is virtuous.

TrendingLive feeds
About