拼写检查器曾经是软件工程的一大壮举（2008）

情况如下：1984年，您被分配为新的MS-DOS文字处理器编写拼写检查器。一些用户（但不是很多）在其PC中将具有640K的内存。您需要支持低至256K的系统。这是一个四分之一兆字节，用于容纳文字处理器，正在编辑的文档以及操作系统所需的内存。哦，还有拼写检查器。

作为参考，在我的MacBook上，/ usr / share / dict / words中的标准词典为2,486,813字节，包含234,936个单词。

诱人的优先选择是比原始文本更压缩的数据格式。 UNIX词典包含stop和stop and stop，因此有很多重复。聪明的trie实现也许可以解决问题...但是我们需要大幅度减少才能从2+兆字节降到100 K左右。

实际上，即使我们可以将拼写检查器词典中的每个单词表示为单个字节，也仅为此需要几乎全部的256K，当然，单字节表示也不起作用。因此，不仅将整个字典保留在RAM中看起来毫无希望，而且将实际的字典保留在RAM中但只有一个索引的情况下也是如此。

现在变得凌乱。我们可以尝试使用字典的一个子集，其中包含最常见的单词，并对其进行大量压缩以使其适合内存。然后，我们提出了一种较慢的基于磁盘的机制来查找其余单词。或者，也许我们使用各种自定义数据库直接跳到完全基于磁盘的解决方案（也要记住，我们不能假设用户有硬盘，因此字典仍然需要处理到360K软盘上磁盘）。

最重要的是，我们需要处理其他一些功能，例如用户向词典中添加新单词。

在1980年代中期写拼写检查器是一个难题。程序员提出了一些令人印象深刻的数据压缩方法来应对拼写检查程序的挑战。同样，有一些非常聪明的数据结构可用于在压缩字典中快速找到单词。这个问题可能需要花费几个月的精力来解决。 （而且，根据记录，将字典的大小从200,000+减少到50,000甚至20,000个单词是一个合理的选择，但是即使那样也不会为幼稚的方法敞开大门。）

快进到今天。 将/ usr / share / dict / words加载到哈希表中的程序是3-5行的Perl或Python，具体取决于您的介意程度。 在此哈希表字典中查找单词是一个简单的表达式，该表达式已内置在该语言中。 就是这样。 当然，您可以想出一些方法来减少加载时间或减少内存占用，但是这种方法很可能并不需要。 基本的实现非常简单，以至于在任何Python教程的早期章节中，读者都可以进行练习。