Do we still need subroutines? [closed]

Question

In Fortran, a clear difference exists between function and subroutine: functions return one value, subroutines return no value. This introduce a cascade of differences between the two. One example is the calling semantics: you can call a function just as in other languages, but in order to call a subroutine you must issue a call statement first.

With the addition of pointers and data types in Fortran95, it appears that there is no technical limitation in making any subprogram a function, and keeping subroutines just for legacy. Functions could return zero (you just return a dummy integer), one, or multiple values (for example, you could return a pointer to an allocated instance of a type, like a C++ STL Pair).

Am I wrong? Do we still need subroutines in Fortran programming due to some feature that subroutines have and functions don't?

Impanel

No, we don't; we don't need do i=1.. loops in languages that have do while..., either. – Diondione

I think this question would work better on programmers.stackexchange.com, as it's very subjective. – Phelia

@David: Read my answer for a non-subjective answer to a non-subjective question. – Impanel

Unless my memory since college has gone, Pascal has (or at least had) the same types of functions and subroutines. I think some versions of BASIC do/did also. Having learned those (and FORTRAN) before C, I found it strange that there were only functions in C! – Rookery

Recall that fortran IV and fortran 77 at least were strictly call-by-reference languages. There was no need to "return" a value at all unless you wanted to be able to writ p = q + estimate(r,s,t) because side-effects of evaluation were the order of the day. Direct descendants of those languages will and should continue to have the distinction because there are descendants. If you don't like that feature of fortran then don't use fortran. Sheesh. – Pettigrew

@dmckee The only parameter passing mechanism endorsed by Real Programmers is call-by-value-return, as Implemented in the IBM\370 FORTRAN-G and H compilers. web.mit.edu/humor/Computers/real.programmers – Mistiemistime

Answer 1

If you search the comp.lang.fortran archives, you'll find discussions about the semantics of functions. IIRC it turns out that it's not clearly specified in the standard what is and what isn't allowed for functions that have side-effects.

For instance, can the compiler optimize

x = foo(args) + foo(args)

into

x = 2 * foo(args)

Or for another example, consider

x = y + foo(y)

What if foo() changes the value of y? Remember that Fortran doesn't have the C concept of sequence points.

In general, the recommendation by several experts is to use functions only if they're pure, otherwise use subroutines. And, that is advice that I follow myself as well.

Mikaela

I cannot upvote you enough. Thanks! – Impanel

And since you are the only one who actually answered technologically, I hunted down a question you answered, put a bounty on it, and awarding it to you as soon as allowed (since I cannot do it on this question anymore). – Impanel

Answer 2

I don't think subroutines are going anywhere. Most other languages allow methods that do and do not return values. I can't see any reason why that's a bad thing. No one should be moved to change a thing.

Legacy alone says that subroutines will persist as long as Fortran does. And as long as Fortran is around, there'll be nothing wrong with writing a method that performs an action and returns nothing.

UPDATE:

Why do you say "hassle"? What's the big deal? I disagree with the idea that subroutines are a "hassle" when they're used in an appropriate situation.

Fortran has maintained a distinction between functions and subroutines since version 77 and probably earlier. Other C-family languages do, too. Why is this suddenly such a hassle? Even the languages that have had pointers and objects for a long time have methods that return void.

Haro

yes, but in new code, is there a reason to go through the hassle of having two different routine styles (which in addition have two different call approaches)? – Impanel

because I find useless to have two routine methods, and I find useless to have to write call every time I invoke a subroutine, while I can just call a function as I do in every other language. I still don't see a valid reason why subroutines should be used at all, today. – Impanel

@Stefano Borini: no one's trying to force you to use features of Fortran that you dislike. Personally, and I suspect I'm not the only Fortran programmer to have this thought, I find pointers much more of a hassle than value-changing-functions-called-subroutines. – Supervisor

@High: the question I asked is different. I am trying to understand if there is a good reason to use subroutines, i.e. in which features subroutines and functions are orthogonal, hence you are forced to use one or the other. If subroutines have no additional features wrt functions, with the additional issue of having to use call, then the answer is "no, technically we can live without them". Otherwise, the answer would be "yes, because subroutines do this and you can't do it with just functions". – Impanel

@Stefano - Better stop writing code in all these "useless" languages. I can call methods that return void in Java or C or C++ or C#. I don't find it useless. I've voting to close this. It's not a real question, subjective and argumentative. – Haro

I think that the person who is subjective and argumentative in this post is you, to be fair. I asked a technical question. Please give me a technical answer. – Impanel

You said "Legacy alone says that subroutines will persist as long as Fortran does". Does this mean that the existence of subroutines today is just for legacy, or is there another important technical motivation of its existence, regardless of the issue of having a function that returns void (technically not possible). – Impanel

@Stefano, I gave you a technical answer. You're not acknowledging or accepting it. – Haro

@duffymo: I don't think so. I asked what is the technical reason today to have both. Your answer is "there's nothing wrong with it", "No one should be moved to change a thing", "I can't see any reason why that's a bad thing" and "legacy". That's not a technical reason. It's your opinion. – Impanel

@Stefano, So's your statement that subroutines are "useless". Your opinion, not shared by any language designer, including those who maintain Fortran. – Haro

@duffymo: what part of "my current opinion that is looking for an answer to form a better opinion" is not clear ? – Impanel

It's clear, just subjective and argumentative. If you'd rather not write subroutines from now on, please refrain from doing so. I'm saying that it's unlikely that you'll ever convince the rest of the world that your opinion should hold for everyone. You seem convinced of the correctness and perfection of your view. By all means, please go ahead and act on it. – Haro

@duffymo: this is totally your words. I've never said "thou shalt not write subroutines". I said "I don't see any use of them, please correct me technically if they are needed", and considering that no other language I know has two different routine semantics, the question is completely understandable. What about trimming down coffee ? – Impanel

"considering that no other language I know has two different routine semantics" - can't I do function (return a value) or subroutine (return void) in C or C++? "What about trimming down coffee?"- Now that's a good suggestion. Thanks for that. 8) – Haro

The distinction predates FORTRAN 77. I don't know how long it goes back, but it didn't look new in FORTRAN 66 when I used it. – Phelia

That's my experience as well. I don't think that requiring legacy code that dates back to Fortran's birth in 1957 to be rewritten would be taken too kindly. I don't see any benefit to it, either. – Haro

but who said anything about rewriting code ?! Please tell me WHERE I said anything about rewriting legacy code to remove subroutines and replace them with functions. – Impanel

You didn't; I can't cite it. You asked whether or not subroutines were still needed. I say they are and always will be. If you'd like to stop using them, you're welcome to do so. Others who choose differently are unlikely to follow your lead or care about your argument. I don't see where this goes from here. I know I have nothing else to offer. We'll see if anyone else does. – Haro

@Stefano - As I said, and most will agree, from a quick view to comments on this question - you're acting like a troll. Please, don't. – Tiptoe

@Tiptoe : No. I think that a lot of people who read this question want to believe that I was trolling with my question, while I just begged for a good technical answer for a reasonable doubt for one who is mostly used to a different programming style. Instead, I mostly got a picture of the helpfulness of some members of the Fortran community on SO. – Impanel

@Rook: in particular when I am attributed phrases I never wrote in the first place, apparently to increase the level of a confrontation which has never been intended to be introduced. With this, I close my comment stream. – Impanel

Still nothing in the thread or the answers mention the technical benefits/disadvantages of subroutines. Are they faster, as they jump back to the position where they are called without returning an extra value? Are they a better practice for certain kind of operations? A couple of code examples could clear that. – Bub

This question was closed 12 years ago. You add no value with this comment. – Haro

Answer 3

You're trying to program C in fortran again, aren't you? ;-)

In my opinion, yes - we do. For if for one reason only - they're easier to grasp, to understand, and they're more widely used than functions.

Also, -1, for I believe this is not a constructive question. If you don't like them, then don't use them.

Tiptoe

What about giving me an answer like the one I had to find myself, which is what I needed ? – Impanel

@Stefano - Your question was do we need them and I stated my opinion. So what more do you want? If you want to spend your time trying ways to circumvent normal usage of subroutines, be my guest. After that you could try to find some other ways to other things. That's the road to paradise, that is. It is however, nonconstructive as 99% people still thinks of them as useful, and doesn't dream of throwing them out (actually, even if they wished they couldn't - fortran Standard demands it). No useful outcome could result in answering this question, therefore my -1. – Tiptoe

Tell me, what practical use could we have by throwing them out? (man, this reminds me of those capslock questions). – Tiptoe

I did not want an opinion. I wanted a technical reason – Impanel

Any other language I am aware of does not have this structure when it comes to subprogram call. When I did F77, I've been taught that the reason for the existence of these two was "with functions you can return only one thing, so if you want to return more complex stuff, you have to use subroutines and output parameters". F77 didn't have types. F90 does, so the motivation I knew about sub/func went amiss. I asked on SO because I was hoping that someone with more experience could provide a good technical explanation, but apparently the Fortran community on SO is different from the python one. – Impanel

@Stefano - Well, that's their's problem, innit? No, the fortran community in here is fine (smallish a bit, but otherwise solid), but the point is, which I emphasise, is that python (or some other ...) is great for messing with, for twiddling and such, and fortran isn't. It is a lang. that just does what it is supposed to do. I mean, I don't mean to bash at you, but your questions do sometimes seem a bit trollish. I cannot for example think, apart from some messy hacks, what answer would satisfy you in this case, and as always with such questions, they end up in flame wars in comments. – Tiptoe

"F77 didn't have types"???? Does "type" mean something different to you than to me? Because fortan 77 certainly support integer and real*8 and complex and char(255) and so on. – Pettigrew

@dmckee : complex types like in TYPE/END TYPE – Impanel

Answer 4

If I understand correctly Stefano is not against the idea of subroutines. The opinion against them is nonsense. He against the usage of different styles for subroutines/functions.

Fortran is imperative programming language. More precisely it is a procedural programming language (and even more precisely it is structured programming language).

In imperative programming we have a state and statements to change it. In procedural programming our tools to do changes are procedures (we localize changes inside procedures). The procedure may or may not return some value. And I don't think that this fact (either procedure return value or not) is so significant reason to have 2 different entities in the programming language. We can have only functions (like in C) and just return something special when we do not actually need to return something (void). Or we can have only procedures and special syntax permitting to return values like in Modula-2, Oberon, ...

The language probably should have only one style to declare procedures. I agree with You, Stefano.

Unfurl

My question is more relative on a potential difference I am not aware of that grants subroutines some special feature which is not allowed in functions. I'd rework the question because apparently it's not clear enough. – Impanel

"The language probably should have only one style to declare procedures." - Why do you believe that? If Fortran has had subroutines and funtions since very early on, and pointers are only a more recent addition that co-exists with subroutines and functions in languages like C, what is the justification for only one procedure style? Fortran isn't Haskell. – Haro

@dyffymo: I do not mean that we need only functions (which have return values) and do not need subroutines (which doesn't have return values). The last one is useful. For example for step-wise program composition. The only thing that I like is uniform syntax to declare both functions and subroutines (like procedure declaration in Modula-2 and its descendants). I do not believe in that but just like it. – Unfurl

Answer 5

The fact that I have to answer myself to this question is insane, but that's how it is.

The difference stems from the fact that you cannot "call functions like in other languages" in Fortran. While in C you can call an integer function without assigning the value, example

int foo() {
    return 5;
}
int main() {
    foo(); // this works
}

In Fortran, you always have to associate a receiving variable. Example

module test
   implicit none

contains
   integer function foo()
      print *, "hello"
      foo = 0
   end function

end module

program hello
   use test
   integer :: x

   x = foo() ! this works
   foo() ! this does not compile

end program hello

Meaning that to "emulate" a void function by returning a dummy integer would still not allow you to call without having a receiver variable.

In Fortran, the void return type does not exist. Technically, you could structure your program with all functions, replace every occurrence of the call statement with x = like seen above, but that would not make your syntax similar to C or other languages anyway, where there is no distinction between void-returning functions and non-void returning functions. subroutines are the only entities that allow to "return void", but the semantic to perform the call is simply different. Apart from that, there's no difference between the two.

Impanel

@Stefano Borini: So I came back to this question at the end of the working day. I see that it has, like most questions along the lines of 'Why does language X (not) have feature Y ?', generated sound and fury signifying nothing. Between comments here, I've spent the day writing Fortran to tackle a computational EM problem, both ignoring and ignorant of, the nicer points of language design that you are getting so worked up about. It really doesn't bother me if Fortran 2008 has features left over from the old days that no-one would include in a language designed today. – Supervisor

"computational EM" - now that would be worth hearing about. HPM, I'd love to know more about how you do it. Finite elements? Something else? Are multiphysics involved? (e.g., induction heating). – Haro

@High: ok, so you are a badass coder. now what ? – Impanel

@Stefano Borini: now it's 17:05 on Friday (local coordinates) and I head off to the pub. Have a good weekend one and all. – Supervisor

The "fact that I have to answer myself" is a sign that you're locked into one way of thinking and don't accept that other might feel differently. If you're saying that StefBortran won't have this behavior, fine: good for you. Fortran has it because fortran has it. End of story. Everything else is tea leaf reading. – Pettigrew

@dmckee : This is not an issue of "feel differently". This is not religion. This is technology. My question had a reason: understand the technological reasons behind a subroutine based approach while most modern programming languages don't have this distinction. If I had the same feedback I got from the fortran community when I asked to the python community What's the point of inheritance in python (see #1020953 ) I would have learned much, much less about python, lot more about the python community. – Impanel

@dmckee :So I kindly ask in the future and to the general public, instead of classifying as troll a person who genuinely questions and inquire about an apparent "technological dogma", to stay in the spirit of SO and try to provide useful, positive answers that convey technological content, rather than "I can't see any reason why that's a bad thing".[period] kind of answer.This is in the interest of whoever wants to better understand a technology, and of the community to provide a positive image. I am on SO since 2 years and strive for helpfulness. Please do the same for the common good. – Impanel