java - 字符串不可变的非技术优势

Question

我想知道从程序员的角度来看字符串类型不变的好处。

技术优势(在编译器/语言方面)可以概括为，如果类型是不可变的，则更容易进行优化。阅读here以获得相关问题。

同样，在可变的字符串类型中，要么您已经内置了线程安全性(然后又很难进行优化)，要么您必须自己进行。无论如何，您都可以选择使用具有内置线程安全性的可变字符串类型，因此这并不是可变字符串类型的真正优势。 (同样，更容易进行处理和优化以确保不可变类型上的线程安全，但这不是重点。)

但是，不可变字符串类型在用法中有什么好处？某些类型不可变的意义何在？这对我来说似乎很矛盾。

在C++中，如果我想使某些字符串不可变，则将其作为对函数的const引用(const std::string&)传递。如果我想要原始字符串的可变副本，请将其作为std::string传递。仅当我想使其可变时，才将其作为引用传递(std::string&)。因此，我只能选择自己想做的事情。我可以使用所有可能的类型来做到这一点。

在Python或Java中，某些类型是不可变的(大多数都是原始类型和字符串)，而其他则不是。

在像Haskell这样的纯函数式语言中，一切都是不可变的。

有充分的理由使这种不一致有意义吗？还是仅出于技术上的低级原因？

Answer 1

What is the point of having some types immutable and others not?

没有一些可变的类型，您将不得不全力以赴地进行纯函数式编程-与目前最流行的OOP和过程方法完全不同的范例，并且尽管功能非常强大，但对许多程序员来说显然具有挑战性(当您确实需要一种无法改变的语言带来的副作用时，会发生什么？当然，在现实世界中编程不可避免地会做这是挑战的一部分-Haskell的 Monads是一种非常优雅的方法，例如，但是有多少种方法程序员是否知道您完全自信地理解它们，并且可以将它们以及典型的OOP构造使用？-)。

如果您不了解拥有多个范式的巨大值(value)(FP范式和关键依赖可变数据的范式)，我建议您学习Haridi和Van Roy的杰作 Concepts, Techniques, and Models of Computer Programming-“21世纪的 SICP”，因为我一旦描述过；-)。

大多数程序员，无论是否熟悉Haridi和Van Roy，都会轻易地承认，至少 一些可变数据类型对他们很重要。尽管我从您的Q中引用了上面的句子，但该观点的观点截然不同，但我相信这可能也是您困惑的根源: 不是“为什么每个都有些”，而是“为什么有些不可变的” 。

在Fortran实现中曾经(偶然地)获得了“彻底可变”的方法。如果有的话

  SUBROUTINE ZAP(I)
  I = 0
  RETURN

然后是一个程序段，例如

  PRINT 23
  ZAP(23)
  PRINT 23

会先打印23，然后打印0- 的数字23 已被更改，因此程序其余部分对23的所有引用实际上都将引用0。从技术上讲，这不是编译器中的错误:Fortran对于哪些内容有微妙的规则您的程序是否可以将常量与变量传递给分配给其参数的过程，并且此代码段违反了那些鲜为人知且不可编译的规则，因此这是程序中的一个问题，而不是编译器中的问题。当然，实际上，以这种方式引起的错误数量高得令人难以接受，因此，典型的编译器很快会在这种情况下切换到破坏性较小的行为(如果操作系统支持，则将只读段中的常量获取运行时错误；或者，尽管开销很大，但传递常量的新副本而不是常量本身；依此类推)，即使从技术上讲它们是程序错误，允许编译器“正确地”显示未定义的行为；-)。

在其他一些语言中强制执行的替代方法是增加参数传递的多种方式的复杂性-最值得注意的是在C++中，带有按值，按引用，按常量引用，按指针，按常量指针等等的东西。然后当然会看到程序员对诸如 const foo* const bar的声明感到困惑(如果 const是某个函数的参数，则最右边的 bar本质上无关紧要……但如果 bar是局部变量，则至关重要)。

实际上，Algol-68可能沿着这个方向走得更远(如果您可以有一个值和一个引用，为什么不引用一个引用呢？还是引用一个引用呢？＆c-Algol 68对此没有限制，并且规则定义正在发生的事情可能是“打算用于实际用途”编程语言中发现的最微妙，最困难的组合)。早期的C语言(只有按值和明确的指针，没有 const，没有引用，没有并发症)，对它的 react 无疑是部分的，就像最初的Pascal一样。但是 const很快流行起来，并且复杂性又开始增加。

Java和Python(以及其他语言)以强大的简化方式突破了这个丛林:所有参数传递和所有赋值都是“按对象引用”(从不引用变量或其他引用，从不包含语义隐式副本，＆c) 。将数字定义为(至少)语义上不可变的，可以避免上面的Fortran代码所展示的“麻烦”，从而保留了程序员的理智(以及语言简单性的这一宝贵方面)。

将字符串像数字一样对待为基本体与语言预期的较高语义水平是完全一致的，因为在现实生活中，我们确实需要与数字一样简单易用的字符串。将字符串定义为字符列表(Haskell)或字符数组(C)之类的替代方案对编译器(在这种语义下保持高效的性能)和程序员(有效地忽略这种任意结构以使字符串使用简单)都构成了挑战(例如，现实生活中的编程经常需要)。

Python进一步增加了一个简单的不可变容器( tuple)，并将散列与“有效不可变性”联系在一起(这避免了对程序员的某些惊喜，例如在Perl中发现的那样，其哈希允许可变字符串作为键)那么为何不？一旦有了不变性(这是一个宝贵的概念，可以使程序员不必学习关于赋值和参数传递的N种不同的语义，随着时间的流逝，N会逐渐增加；-)，您也可能会从中获得全部 yield ；-) 。