why not language X

rcbsdpge said:
Was Fortran or Ada ever suggested for base system alongside C.
Click to expand...
It is very difficult or nearly impossible to build an OS kernel in Fortran. The reason is that it uses a memory management model that doesn't do well with pointers, and is highly static. There are rare exceptions, I think the PrimOS kernel was mostly in Fortran with a little bit of assembly. But just because it was done once doesn't mean it is a good idea.

For user-level applications, Fortran is perfectly viable.

I keep retelling the same story: When VMS shipped, the OS development group made sure that for every language that is officially supported by DEC, at least one of the base OS utilities is written in that language. That's to make sure that all runtime libraries for all languages are shipped and installed with the base OS. Fortran was not a problem at all; the fun one was RPG-II (which is usually a batch processing report generation language); with considerable effort, the monitor utility (sort of the equivalent of ps, top, df and similar tools) was written in RPG-II.

cadahl said:
Re Fortran, it's not enough that the programming language exists, there needs to be an argument to use it... what does it offer that C does not have?
Click to expand...
See above. It could be used, if someone wanted to use additional languages. There are certain things that it is very good at. Fortran code tends to execute faster, for a variety of minor reasons (no modifiable parameters, no pointers, easy to use single-precision floating point, the optimizer can do memory placement without worrying about pointers or aliasing).
 
cadahl said:
Re Fortran, it's not enough that the programming language exists, there needs to be an argument to use it... what does it offer that C does not have?
Click to expand...
LOADS of stuff, actually. Use C for heavy numerical computations, then do the same using Fortran. You will see for yourself. It is day/night difference.
That doesn't mean C is bad. It is essentially high-level Assembly, not a high-level programming language. As such, it is closer to the hardware, therefore it is great for writing operating systems or low-level drivers/libraries. However it sucks big time for pretty much anything else. Why? Because it has zero array support (unless you call pointers "arrays" for some reason), no numerical functions other than the very basics, no complex numbers, no, no, no... And I don't necessarily consider that a flaw; C is just not made for that kind of stuff.
Sure, you can do numerical computations with C. In fact I see a recent trend to do so, but it's more because people who already know some C don't want to learn another language - definitely not because C is good for that purpose. Sure, any programming language can be used for any purpose - if you really want to. But if you choose C for numerical/scientific computations, you will need to re-invent the wheel yourself - or use external libraries which may or may not do what you need. The question is why on Earth would you want to do that.
Fortran, on the other hand, has excellent built-in array support, a plethora of tools for numerical computations that make your life way easier, zero "header hell", and a sane usage of pointers (that is, when they are really needed, instead of using them for everything). Furthermore, Fortran doesn't let you shoot your own feet - which is actually very easy when using C. As an additional bonus of all that it compiles source code faster, the compiler can do better optimizations, and the resulting executable is either as fast or faster, depending on the application.

Now C++ tried to add some of the stuff C lacks, but it did so in a typical C++ way. For example, yes, it has arrays, but you will still need to implement templates yourself, even for basic operations - a.k.a re-inventing the wheel again. And guess what, templates are abysmally slow during compiling. But even if they did arrays properly, C++ still lacks a lot of numerical stuff Fortran has built-in. You would still need external libraries for pretty much anything, numerical-wise.

Last but certainly not least, I don't think "there needs to be an argument" to use Fortran. After all, it is the first high-level programming language ever made, and the reason the term "compiler" was invented. In fact, I don't see why there needs to be an argument to use any programming language. You use it or not.
If there has to be an argument to use a language, that would be why on Earth the "first" programming language in the job market (according to TIOBE and other indices) is interpreted - for God's/Devil's sake, interpreted.
 
This is highly context sensitive. My question is: why use Fortran in the FreeBSD base system? Is there a case for it? What would be written or rewritten in Fortran?
 
Pap said:
After all, it is the first high-level programming language ever made, and the reason the term "compiler" was invented.
Click to expand...
I don't see that as a good argument for using Fortran (nor Cobol). In the case of Fortran, there are good arguments though: It creates code that runs fast, it has nice language features for numeric computation and HPC, and it builds on a huge set of experience and accumulated libraries in scientific and HPC computing.

Pap said:
If there has to be an argument to use a language, that would be why on Earth the "first" programming language in the job market (according to TIOBE and other indices) is interpreted - for God's/Devil's sake, interpreted.
Click to expand...
There is nothing inherently wrong with interpreted languages. They offer a good compromise between the cost of development and the cost of computation. And some of them are designed to be programmer friendly, in particular beginner friendly, which is why they are used as a starting point in computer education.

cadahl said:
This is highly context sensitive. My question is: why use Fortran in the FreeBSD base system? Is there a case for it? What would be written or rewritten in Fortran?
Click to expand...
In the base system, one of the most important things is to keep it light, and reduce the number of tool chains. Since all the existing base code is in a single compiled language (C++/C), and since that language can do what is needed for base with halfway decent efficiency (both of coding/maintenance and at runtime), no need to change. If one were to introduce another compiler chain into base, it would have to be either because the definition of base is being broadened, or to address a shortcoming of C++/C. For the latter, Rust is being discussed (and we don't need to rehash that in this thread). The former sounds like a bad idea.
 
You must log in or register to reply here.
Back
Top