Skip to content

Latest commit

 

History

History
80 lines (50 loc) · 4.41 KB

comment_complicated_pl.md

File metadata and controls

80 lines (50 loc) · 4.41 KB
Raw

Don't try to solve all problems with programming languages

-- Comment: What's next for language design? (2017)

Copyright © 2021.11.22 Lin Pengcheng. All rights reserved.

If programming language is a tool, there is no absolute security tool in this world, only scientific methods, architecture and systems are the guarantee of security.

The reason why all the questions in this article are too complicated is because they try to solve all the problems in a programming language.

If you use the correct programming paradigm and architecture, these problems are very simple. If the programming paradigm and architecture are wrong, you don't want to correct it, you just want to solve the resulting problem with a bunch of programming language complex features. If a programming language pursues such a goal, it must be too complex to use. This is a macro strategy and method is wrong, do not want to correct it, but just want to solve the problem with a variety of micro-tactical techniques, This results in painstaking but extremely ineffective results. It's like a building with the wrong architecture and construction methods, not only is it dangerous, but the hard - working remedies will not have good results. .

In terms of common sense in management science, the entire development tool chain should also follow the principle of professional division of labor, otherwise things will be complicated.

In my The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model, it is based on mathematical model, operational research, and management science, these problems are very simple.

  • Data is centrally managed by the warehouse. they are simple such as access, verification, type, standardization, and etc.

  • The logic of each workshop is very simple, short, independent, They are simple & natural such as heterogeneous parallel, Coroutines, async/await, effect systems, module system, Errors, and etc.

  • Use the scheduler to achieve global optimization.

Reference

不要试图用编程语言解决所有问题

-- 评: What's next for language design? (2017)

版权所有 © 2021.11.22 林鹏程， 保留所有权利。

如果说编程语言是一种工具, 这世界上没有绝对保证安全的工具, 只有科学的使用方法、架构和制度才是安全的保证.

该文章的所有问题之所以太复杂是因为试图用编程语言解决所有问题. 这是很多复杂的编程语言所犯的错误.

这些问题如果使用正确的编程范式和架构, 它就是一个很简单的问题. 如果编程范式和架构错了, 不去纠正, 而只想用一堆复杂的编程语言特性解决由此引发的问题， 如果一种编程语言追求实现这样的目标, 那它一定复杂得无法使用. 这属于宏观的战略和方法错了，不想着去纠正, 而只想以各种花样的微观的战术技术解决问题， 费尽心力, 效果惨淡。就象一座建筑, 架构和建筑方法错了, 不仅危险,而且再努力的补救措施也不会有好的结果.

用管理科学的常识来说, 就是整个开发工具链也要遵循专业分工原则, 否则就是自讨苦吃, 吃力不讨好, 事倍功半.

在我的基于数学的大统一编程理论：纯函数管道数据流和基于原则的仓库/车间模型里, 它基于数学模型、运筹学、管理科学, 这些问题非常简单.

  • 数据由仓库集中管理,存取,校验,类型和标准化等问题就简单了

  • 每个车间逻辑都非常简单, 短,独立. 异构并行、异步、协程和模块等是很简单和自然的

  • 使用调度器可以实现全局统一优化.

参考文献