（四）集算器的目标
在设计目标上，集算器希望提升这两方面的效率：计算的描述效率和计算的执行效率。
这两个效率都容易理解，如果描述效率太低，就意味着开发成本太高，很难写出程序进行计算；而如果执行效率低，则需要运行很久才能得到结果，那实用价值也就大打折扣了。事实上，执行效率本质上也是描述效率，因为我们在软件层面不可能提高硬件性能，只能寄希望于设计出更高效的算法，而如果编写高效算法太困难甚至写不出，那就解决不了执行效率的问题了。
那么集算器用什么办法来达到这两个目标呢？
我们知道，计算机只能认识并执行形式化的程序语句。用计算机解决问题的过程，也就是把问题算法翻译成某种程序语言的过程，如果语言的语法体系和数据类型设计得不好，就可能发生把问题解法翻译成代码的难度大于解决问题本身的现象，也就是明明知道怎么做却很难写出程序来；有时候甚至真地写不出来，就出现明明知道有好的高效算法却无计可施，只能使用笨办法去低性能计算。
这种现象在结构化数据计算领域是普遍存在的，特别是对于很常见的过程式（需要多步骤才能完成）和有序计算。这主要是作为结构化数据计算的主流程序语言SQL造成的，我们举两个不太复杂的例子分别说明：
- 找出一支股票最长连续上涨了多少天
这个问题对于Java或C++程序员来讲非常简单：做个初值为0的计数器，把数据按日期排序后遍历，发现上涨就将计数器加1，下跌则清0，最后看这个计数器出现过的最大值，这是个很自然的思路。但是用SQL就很困难，需要人为地制造出日期的序号后，再产生一个分组标志，把上涨的日期和前一天分成一组，下跌的日期分到另一组，然后计算最大的分组COUNT()值，这个思路下写出的代码也很长也很难理解。
- 从10亿条数据中找出最大的前10名
熟悉算法的程序员都知道，解决这个问题不需要把10亿条数据全排序。只要产生一个有10个成员的空集合，然后遍历数据，过程中始终保持这个小集合是当前已遍历过数据中最大的10个，数据只要遍历一次，内存占用也很小。但SQL却很难甚至无法描述这个过程，逻辑上只能采用大排序后取前10名的算法，简单情况时还能寄希望于数据库系统在工程上的优化，而情况复杂就束手无策（比如有子查询和JOIN等情况）。
而这两个例子中的算法过程用集算器的程序语言都很容易写出来。
确切地说，集算器并不负责解决问题，想出（高效）算法是程序员的任务。集算器的任务就是提供更好的数据类型及相关的语法体系，使得编写这类计算更容易更简洁，更贴切人们的自然思维习惯。当然，这个目标也没有止境，集算器会一直向在这个方向努力，只要是能提高这两个效率的方法，我们都会尽量将其纳入到集算器的体系中去。