这取决于上下文。

在类pascal语言中，函数和过程是不同的实体，不同之处在于它们是否返回值。他们的行为不同。语言语法(例如;过程调用表单语句;你不能在表达式中使用过程调用，而函数调用不构成语句，你必须在其他语句中使用它们)。因此，pascal培养的程序员会对这两者进行区分。

在类c语言和许多其他当代语言中，这种区别已经不复存在;在静态类型语言中，过程只是带有有趣返回类型的函数。这可能就是为什么它们可以互换使用的原因。

在函数式语言中，通常没有过程这样的东西——所有东西都是函数。

如果我们在这里与语言无关，那么过程通常指定了可靠且幂等地实现某个结果所需的一系列行为。也就是说，一个过程基本上就是一个算法。

另一方面，函数是较大程序中某种程度上独立的代码段。换句话说，函数是过程的实现。

这取决于上下文。

在类pascal语言中，函数和过程是不同的实体，不同之处在于它们是否返回值。他们的行为不同。语言语法(例如;过程调用表单语句;你不能在表达式中使用过程调用，而函数调用不构成语句，你必须在其他语句中使用它们)。因此，pascal培养的程序员会对这两者进行区分。

在类c语言和许多其他当代语言中，这种区别已经不复存在;在静态类型语言中，过程只是带有有趣返回类型的函数。这可能就是为什么它们可以互换使用的原因。

在函数式语言中，通常没有过程这样的东西——所有东西都是函数。

这是一个众所周知的老问题，但我想分享一些关于现代编程语言研究和设计的更多见解。

基本的答案

Traditionally (in the sense of structured programming) and informally, a procedure is a reusable structural construct to have "input" and to do something programmable. When something is needed to be done within a procedure, you can provide (actual) arguments to the procedure in a procedure call coded in the source code (usually in a kind of an expression), and the actions coded in the procedures body (provided in the definition of the procedure) will be executed with the substitution of the arguments into the (formal) parameters used in the body.

函数不仅仅是一个过程，因为返回值也可以在函数体中指定为“输出”。函数调用或多或少与过程调用相同，除了还可以从语法上使用函数调用的结果(通常作为其他表达式的子表达式)。

传统上，使用过程调用(而不是函数调用)来表示必须没有感兴趣的输出，并且必须有副作用以避免调用为无操作，因此强调命令式编程范型。许多传统编程语言(如Pascal)同时提供“过程”和“函数”来区分这种有意的风格差异。

(To be clear, the "input" and "output" mentioned above are simplified notions based on the syntactic properties of functions. Many languages additionally support passing arguments to parameters by reference/sharing, to allow users transporting information encoded in arguments during the calls. Such parameter may even be just called as "in/out parameter". This feature is based on the nature of the objects being passed in the calls, which is orthogonal to the properties of the feature of procedure/function.)

However, if the result of a function call is not needed, it can be just (at least logically) ignored, and function definitions/function calls should be consistent to procedure definitions/procedure calls in this way. ALGOL-like languages like C, C++ and Java, all provide the feature of "function" in this fashion: by encoding the result type void as a special case of functions looking like traditional procedures, there is no need to provide the feature of "procedures" separately. This prevents some bloat in the language design.

Since SICP is mentioned, it is also worth noting that in the Scheme language specified by RnRS, a procedure may or may not have to return the result of the computation. This is the union of the traditional "function" (returning the result) and "procedure" (returning nothing), essentially same to the "function" concept of many ALGOL-like languages (and actually sharing even more guarantees like applicative evaluations of the operands before the call). However, old-fashion differences still occur even in normative documents like SRFI-96.

I don't know much about the exact reasons behind the divergence, but as I have experienced, it seems that language designers will be happier without specification bloat nowadays. That is, "procedure" as a standalone feature is unnecessary. Techniques like void type is already sufficient to mark the use where side effects should be emphasized. This is also more natural to users having experiences on C-like languages, which are popular more than a few decades. Moreover, it avoids the embarrassment in cases like RnRS where "procedures" are actually "functions" in the broader sense.

理论上，可以用指定的单元类型指定函数作为函数调用结果的类型，以表明结果是特殊的。这将传统过程(其中调用的结果是不感兴趣的)与其他过程区别开来。一种语言的设计有不同的风格:

As in RnRS, just marking the uninterested results as "unspecified" value (of unspecified type, if the language has to mention it) and it is sufficient to be ignored. Specifying the uninterested result as the value of a dedicated unit type (e.g. Kernel's #inert) also works. When that type is a further a bottom type, it can be (hopefully) statically verified and prevented used as a type of expression. The void type in ALGOL-like languages is exactly an example of this technique. ISO C11's _Noreturn is a similar but more subtle one in this kind.

进一步的阅读

作为从数学中衍生出来的传统概念，有大量的黑魔法是大多数人都懒得知道的。严格地说，你不可能像你的数学书那样把所有事情都弄清楚。计算机科学书籍可能也提供不了太多帮助。

关于编程语言，有几个注意事项:

Functions in different branches of math are not always defined having same meanings. Functions in different programming paradigms may also be quite different (even sometimes the syntaxes of function call look similar). Sometimes the reasons to cause the differences are same, but sometimes they are not. It is idiomatic to model computation by mathematical functions and then implement the underlying computation in programming languages. Be careful to avoid mapping them one to one unless you know what are being talked about. Do not confuse the model with the entity be modeled. The latter is only one of the implementation to the former. There can be more than one choices, depending on the contexts (the branches of math interested, for example). In particular, it is more or less similarly absurd to treat "functions" as "mappings" or subsets of Cartesian products like to treat natural numbers as Von-Neumann encoding of ordinals (looking like a bunch of {{{}}, {}}...) besides some limited contexts. Mathematically, functions can be partial or total. Different programming languages have different treatment here. Some functional languages may honor totality of functions to guarantee the computation within the function calls always terminate in finite steps. However, this is essentially not Turing-complete, hence weaker computational expressiveness, and not much seen in general-purpose languages besides semantics of typechecking (which is expected to be total). If the difference between the procedures and functions is significant, should there be "total procedures"? Hmm... Constructs similar to functions in calculi used to model the general computation and the semantics of the programming languages (e.g. lambda abstractions in lambda calculi) can have different evaluation strategies on operands. In traditional the reductions in pure calculi as well in as evaluations of expressions in pure functional languages, there are no side effects altering the results of the computations. As a result, operands are not required to be evaluated before the body of the functions-like constructs (because the invariant to define "same results" is kept by properties like β-equivalence guaranteed by Church-Rosser property). However, many programming languages may have side effects during the evaluations of expressions. That means, strict evaluation strategies like applicative evaluation are not the same to non-strict evaluation ones like call-by-need. This is significant, because without the distinction, there is no need to distinguish function-like (i.e. used with arguments) macros from (traditional) functions. But depending on the flavor of theories, this still can be an artifact. That said, in a broader sense, functional-like macros (esp. hygienic ones) are mathematical functions with some unnecessary limitations (syntactic phases). Without the limitations, it might be sane to treat (first-class) function-like macros as procedures... For readers interested in this topic, consider some modern abstractions. Procedures are usually considered out of the scope of traditional math. However, in calculi modeling the computation and programming language semantics, as well as contemporary programming language designs, there can be quite a big family of related concepts sharing the "callable" nature. Some of them are used to implement/extend/replace procedures/functions. There are even more subtle distinctions. Here are some related keywords: subroutines/(stackless/stackful) coroutines/(undelimited delimited) continuations... and even (unchecked) exceptions.

C语言示例:

// function
int square( int n ) {
   return n * n;
}

// procedure
void display( int n ) {
   printf( "The value is %d", n );
}

尽管你应该注意到C标准没有谈论过程，只有函数。

我反对在大多数答案中反复看到的东西，函数之所以成为函数，是因为它返回一个值。

函数不是任何返回值的旧方法。事实并非如此:为了让一个方法成为一个实函数，它必须总是在给定特定输入的情况下返回相同的值。不是函数的方法的一个例子是大多数语言中的随机方法，因为尽管它确实返回值，但值并不总是相同的。

因此，函数更类似于映射(例如，对于一维函数，x -> x')。这是常规方法和函数之间的一个非常重要的区别，因为当处理实函数时，它们被求值的时间和顺序应该永远不重要，因为对于非函数并不总是如此。

这是另一个方法的例子，它不是函数，但仍然会返回一个值。

// The following is pseudo code:
g(x) = {
  if (morning()) {
     g = 2 * x;
  }
  else {
   g = x;
  }
  return g;
}

我进一步反对过程不返回值的概念。过程只是谈论函数或方法的一种特定方式。这意味着如果你的过程定义或实现的底层方法返回一个值，那么猜猜这个过程返回什么值。以SICP中的以下片段为例:

// We can immediately translate this definition into a recursive procedure 
// for computing Fibonacci numbers:

(define (fib n)
  (cond ((= n 0) 0)
        ((= n 1) 1)
        (else (+ (fib (- n 1))
                 (fib (- n 2))))))

您最近听说过递归过程吗?他们在讨论一个递归函数(一个实函数)，它返回一个值，他们使用了“过程”这个词。那么，有什么不同呢?

另一种思考函数的方式(除了上面提到的意义)是作为一个理想的抽象表示，如数字1。过程就是那个东西的实际实现。我个人认为它们是可以互换的。

(注意，如果你从我提供的链接中阅读了那一章，你可能会发现更难理解的概念不是函数和过程之间的区别，而是过程和过程之间的区别。你知道递归过程可以有迭代过程吗?)

过程的类似物是配方。例如;假设你有一台叫派的机器，这台机器输入(水果、牛奶、鲜花、鸡蛋、糖、热量)的原料，然后这台机器返回一个派。

这台机器的表示可能是这样的

make-pies (fruit, milk, flower, eggs, sugar, heat) = {
   return (heat (add fruit (mix eggs flower milk)))
}

当然，这不是做派的唯一方法。

在这个例子中，我们可以看到:

A       function     is to a     machine
as a    procedure    is to a     recipe
as      attributes   are to      ingredients
as      output       is to       product

这个类比是可以的，但当你考虑到当你在处理一个计算机程序时，一切都是抽象的，它就不成立了。所以不像机器的配方我们比较的是两个本身就是抽象的东西;这两件事很可能是同一件事。我认为它们(出于所有意图和目的)是同一件事。