Skip to content

human-lang/draft

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

45 Commits
 
 
 
 

Repository files navigation

The Design Draft Of Human Programming Language

Human 编程语言设计草案。

当前编程语言存在的问题 及其解决方案概略描述

本质问题 及其解决

最主要和最本质的问题是没有从 人类思维本质 出发去设计,而是从机器或逻辑角度去设计编程语言。 我知道读者一定对什么是人类思维本质产生了疑问,而且会疑惑难道就没有别人想过这个问题吗。对此 我的声明是,本人的智识有限,还望各位读者多从接纳未知可能性的角度去多思考这个问题和模式。

略知晓编程语言历史的人都知道,目前存在的上千种编程语言中有两大高山,即 C 和 Lisp ,分别代表了 主流的命令式和函数式两种风格。C 一直是工业界主流大众语言,常用于系统编程。而 Lisp 则相对小众, 一般用于人工智能等方面。最近二十多年里比较流行的语言有 C++, Java, VB, C#, Objective-C, Haskell, Erlang, Prolog, Python, Ruby, JavaScript, PHP, 还有近几年被创造出来的 CoffeeScript, Scala, Elixir, Clojure, Rust 等。我们不难看出越新近的语言,会更多的融入 Lisp 的优点。有人说是越新的 编程语言越趋向于 Lisp 化,不过我更愿意相信是两者平分天下才是历史的趋势。

至于未来编程语言如何发展,在我们现在有了一定量的计算和存储能力后,我认为从 人类思维本质 出 发才能创造出和自然语言一样可以历经千年而不变其宗的编程语言,然后再把 SQL 和 CSS 等领域特定语言 (非图灵完全)构建于其之上,甚至把上游的汇编语言也反推导回去,就像我们去思考哲学问题一样。

类继承和原型继承等概念构建模式 及其解决方案

  • 概念太抽象

初次接触编程语言的人在学会基本语法后,接下来就是搞清楚 "类", "对象", "变量", "静态变量", "实例 变量" 等一大堆关于数据的抽象概念。这些概念及其关系在日常生活里没有大致相似的类比,因为编程语言 是用常规人类不擅长的逻辑去模拟现实世界的数据和关系,而不像小说和绘画等用自然语言或图像去模拟和 解释世界。

  • 类继承偏向强调以数据为思考中心

类继承是人类发明的对客观世界的数据整理谱系,例如对生物界的"界门纲目科属种"垂直划分方法,对日常 生活的"美食电影娱乐酒店丽人结婚亲子购物健身"平铺划分方法,这些在本质上只是偏整理性质的数据产出 而已,软件核心关注的是如何达成用户的需求,也是一系列行为场景。数据是按照逻辑来变化的,在数据分 类中体现出的意图才是用户真正想要关心的,也即是数据和逻辑在一起才构成了本质。

  • 类继承示例 及其问题
class Book(object):                                            # 声明 Book 类
    def __init__(self, name, author):                          # 初始化函数,及其参数
        self.name   = name                                     # 绑定 name   值
        self.author = author                                   # 绑定 author 值

book1 = new Book(name="逻辑哲学论", author="维特根斯坦")       # 声明一个 Book 实例(instance)
book1.name                                                     # 访问该 book1 的 name 属性

在分析前,我想先请求有编程经验的读者试着站在对编程一窍不通的普通人的角度去理解这段代码。这段代码 加上了注释后是很容易理解其意图的,即是我们用计算机创造了一本维特根斯坦写的书,并可以看到书名。我 个人觉得怪异的是为什么 new 一个抽象类就可以得到一本书呢,这在日常思维里有点费解,我们又不需要去因 为得去理解物质的运作原理而去创造原子,质子,光子等各种人类根本不可能直接看见的东西。我们需要的只 是一本看得见摸得着的书即可。为了避免误解和困扰,我再强调一次,"new 一个抽象类" 是一件很怪的事情。

而我们再来看看日常思维是如何表达这一意图的,"有一本书,书名是逻辑哲学论,作者是维特根斯坦"。在这 里,我们涉及到了一个名词, 叫"书", 一般情况下我们的脑海里会马上浮现出任何一本想到的书的样子或性质 ,然后在其封面放上"逻辑哲学论"和"维特根斯坦"两处文字,并可能会细微地做各种相关的联想或猜测,这就 形成了一个完整的思维过程。

所以可以对比得到,我们注重的不是创造这一行为本身,而是强调通过一个思维过程,我们创建了关于一本书 的场景,而不是关注点过分落在了 Book 数据结构上面。

目前我想到设计的方案是这样的:

$Book:                                                         # 声明 Book 上下文概念
    name:                                                      # 声明 name   属性, 数据类型未定
    author:                                                    # 声明 author 属性, 数据类型未定

book1 = 1.Book(name="逻辑哲学论", author="维特根斯坦").        # 声明具体一本书的上下文
book1.name.                                                    # 访问该 book1 的 name 属性

和 Python 代码一样是分成两部分,上部分定义了 Book 上下文概念部分,有编程经验的人理解起来会相对来 说更偏向数据结构图,格式类似 YAML 。下部分则开始描述行为, 和 Python 代码的不同点有两个,一个是用 "1." 代替了 "new ", 和自然语言里声明一本书语义一致。另一个 是末尾多了 "." ,这符号在 Python 等面向对象功能的编程语言里是没有的(并发函数式语言 Erlang 是有要 求语句以 "." 结尾的)。这是 Human 编程语言里 组合式 的意思,实际上是

new(1, Book(name="逻辑哲学论", author="维特根斯坦"))

的简略写法,在这两个参数组合在默认的情况下只有 new 函数是符合接受的。这里的提示信息有,该组合里有 两个元素,并且第一个是 1 数字, 第二个是一个上下文概念带着两个参数。在这样足够信息的情况下,new 函 数执行它, 并后返回一个 Book 上下文。

该上下文会绑定到 book1 变量,即目前剩下的语句是

book1 = result

其也是组合式,

book1.=.result.

展开的完整表达应该是

def(book1, "=", result)

即是把 result 值绑定到 book1 变量上。下一句也是用 "." 结尾的组合式来访问其属性的。

综上我们可以得知 Human 编程语言主要把代码分成了两部分,即数据和行为,所以 Context 数据定义是层级 式的,而函数行为是组合式的。组合式在本质上也是一个 Lisp 方言。

静态语言和动态语言 及其解决方案

对于静态语言,我在理论和实践方面都很缺乏。以下只是一些零碎想法。

  1. Human语言虽然是动态语言,但是因为Context限制,所以鼓励静态化类型信息了。
  2. Human某部分静态,即@static,就是真的是二进制静态语言的,同时就要求参数类型确定了。
  3. human语言应该支持内部动静态的多进程化。并且支持内嵌其他动态语言解释器。
  4. 任何类型都是上下文,甚至字符串,整数。只是这些整数被编译为静态的而已。
  5. 加减乘除在C这个静态语言里是属于什么语法,除了函数以外。只是专门加的吗。因为在面向对象语言里是实现为方法的。
  6. Human 里的静态就是静态的,即内部是黑盒子了,不管是不是已经编译为机器语言了。

强类型和弱类型 及其解决方案方案

我听说类型系统是个很专业的领域,以下也只是我的一些零碎刑法。

  1. 因为你知道这个上下文用来做什么,所有你确定应该返回什么。多类型,或不确定类型(但知道这是我们已经定义过的,比如GSON),或者动态新建一个Context(?)。那所有上下文位置你应该都是可以找到的,如果存在但是找不到,那就新建一个了。
  2. 有上下文后,信息足够简明,是否可以做到对大部分进行类型推导了?!
  3. 不要for循环式的列表推导,而是用形容词列表依次处理。for遍历容易多层混淆。如果多个形容词,也即是循环类型的上下文,可以知道自己在第几层,并用类似_1,_2,的方式引用上层,或者指定引用哪个循环上下文。这样也有利于扁平式。
  4. JavaScript里除了基本数据类型,就是对象和函数。而函数是带函数的对象,并且是原型继承。
  5. 写程序过程中得及时更新关系图,为单层声明,表示为JSON(以后可以作可视化分析)。如果是多对多,把关系类作为键。主要目的还是为了方便程序分析。类应该是大写。所有程序中用到的类必须在JSON里声明。这一切都是为了快速理解和清晰。这样一定意义上可以促进动态类型语言有静态化,便于类型推导。
  6. 基本数据类型是指可以通过01进行逻辑变换得到的。
  7. 基本类型就是维基百科标准名字,比如Integer(size),String(unicode),Array(array,list),List,Stack ,Hash(linked,sorted),Bool,,这样API不变,单还是可以用几个基本类型来思考。Array可以声明元素是否一个类型,声明了就不可以变了,反序列化会检查这些值(类名和__type__一致,其实这两个组合已经覆盖绝大部分情况了吧?)。 接上面,一个Context里,和Python类似,首先__id__,hash,type,等。
  8. 语言异常?类型检查我们一定程度上有了。todo
  9. 一个对象.context(函数名或属性名)返回那个context,属性可以认为是函数的直接返回,即类是函数,new之后直接返回就是基本类型数据。
  10. 用infer,表示某Hash是啥类型type,比如linked。
  11. 有些是符号,有些是对象(考虑类型)。
  12. 对具体命名的变量的每个操作,都记录引用,这样这个变量就不能轻易改变值或类型。
  13. 每个值都有其类型,类型有其范围(Range),这个参考 Haskell。为了证明 dict = {"a":0\,"b":1,
  14. 基本类型应该都可以转换。
  15. 洗数据时的数据类型范围证明。17zuoye 数据各种异常太多啦,不过估计其他有一点历史的大一点的公司都是。
  16. 就像英文单词首尾对识别度影响最大一样,在Human组合式里尽量利用首尾,这样尾部最好是数据类型,就像单词的词性一样。

线性逻辑导致的软件复杂性 及其解决方案

  1. 上下文意味着没有继承,只有连接。递归是概念内部的,或者上下文内的,所以应该不会太复杂。
  2. human语言里定义的所有上下文意味着显示了项目的复杂度的绝对性。
  3. 算法的难以理解,正是因为其复杂度太高了,所以更需要上下文编程。
  4. 69页。乔姆斯基,重视语法超过语义。对语法的重视(繁琐或矛盾的细节),导致程序的复杂性。所以上下文编程重点正是把重点放回语义的本源,并以此展开,这样就不会被逻辑控制。
  5. 组合对象技术,比如Rails里的6.weeks.ago。并不是方法链级调用,而是组合才发生这种可能性。这样避免复写6.weeks.ago。这是更强大的组合式思考上下文。最后多加一个点表示是句子,从而组合。 Rails里看着简单,实现复杂,记忆规则也复杂。组合就简单,符合人类思维,在组合里,小写自动解释symbol。
  6. 并没有简单和复杂之分,只是因为上下文。不过直觉和记忆是很神奇的。
  7. 人类可以存在,却无法解释实在。所以概念很复杂,上下文容易理解。
  8. 世界是复杂而又简单的,这种复调同像性在世界各个远近高低都是。小孩子觉得世界简单,大人觉得世界复杂,小孩子觉得大人复杂,大人觉得小孩子简单。显著区别的人可以划分为有限数个(比如生物类属),类似的可以有无穷多(比如一到无穷)。但是这一切其实只是人类思维使然而已。
  9. Human程序语言 导致的结果是程序在执行和语义上更适合被分层,便于调试,降低复杂度。
  10. 比如 Array API 的操作函数可能就十几二十几个,但是因为这些函数返回的还是 Array 就不觉 得其复杂了,只是觉得简单的多而已。举个例子,流水账易于理解,正是因为内在逻辑的扁平型, 而康德哲学难以理解,看了下一个段落,就忘了上一个段落,正是因为他指的概念之间及其错综复杂。
  11. 优化不意味着难以维护性,只是因为发觉了业务内在更多的复杂性。如果还是听觉,那就难以维护了。所以得用视觉。
  12. 大屏意味着视觉化,IDE也是,但是IDE太复杂?!或者不是真正编码想要的视觉化。
  13. 以有限性去推断无限性是不可能的,人类思维是无限和未知的(背后的机制),所以人工智能是不可能的。虽然一定程度上可能,但是规则还是太复杂了。即世界不是由相对论或某几个基础定律等所决定的。
  14. 人与人之间千差万别,除了人的复杂性外,用于理解区别的各种上下文也是关键,因为我们对于上下文是如此熟悉。
  15. 程序的复杂性证明了简单的东西组合后不一定简单。简单的只有直观的东西。
  16. 俊晨说的 luigi 极大地改善了代码复杂度。我现在认为是因为其中提取了内部逻辑的内省。递归只是函数级别的,效果还比不上类组织(以IO为基础)。
  17. 内省是解决软件复杂度的中心,所以在各个层次上思考why,what,how。
  18. AppleScript的问题在于语言的复杂性,而没有明白程序的核心在于逻辑,而不是直接加入自然语言方式到程序语言里。正确方式是永
  19. 代码复杂度不能超过需求复杂度,需求复杂度即解释。
  20. 取消new关键字。完美的简单标准。越复杂越形式,helloworld就简单拉。1. one. another. 都是等价的。编程语言应该是简单的,很快被学会,这样可以释放精力给设计程序。语言应该尽量隐藏自己。
  21. 上下文对抗的正是复杂度。
  22. 看数据结构只是因为其比函数更简单和图形化,并有流转的依赖图。而函数则太复杂了不容易搞清楚。
  23. 世界的繁复杂多让人忘了世界的本质,比如如何高效学习。
  24. 对于复杂度而言,不是简单的位数,而是涉及元素的综合复杂度。比如100100和101101复杂度是不一样的。有人认为简单,但是在其个人而言,也是后者比前者复杂的。
  25. C++ 用数组表示字符串,是想为了高效。而从抽象和解决复杂度角度看,也许编程语言提供分析复杂度比较好。
  26. 逻辑的本质在于约定,它的实现和执行在于人类发现了同样关系的等价实现。比如晶体管到电子(todo,用对的词)。至于本质为何只有与或非,也许就是在于比如阴阳之道,道教的一生二,二生三,都是类似的描述。但这并不是人类思维的本质,只是可被分解成的单元而已,本质还是人类思维的存在性在于寻找所谓的有意义性,一种信念。所以,也可以理解,日常生活中不太用复杂逻辑的,而是尽可能马上明白的意义。
  27. 企业级开发没有明白模块的本质,数据交换最好是单向的,多个相似系统协作会出人类思维本质的复杂性问题,一个死的,一个活的,这样就简单多了。所以多系统不要相互依赖,及时依赖,那也是函数级别的抽象依赖。

领域特定语言 及其解决方案

解决软件内在复杂性是 Human 的目标

软件设计的定义

软件设计是一项非常富有挑战性的智力活动,它专注于把大脑思维映射到多层次抽象的计算机逻辑体系里。

大脑的工作原理非常神秘,虽然我们已经大概知道大脑各个脑区的表象功用(有人类比当前的脑科学只是衡量了一下各个区域的温度而已 ,然而具体如何工作还是所知 甚少,不得其法。从一个结果的,外在的,总结的,直观的,笼统的角度来说,软件设计从任何方面来说 应该尽量可以被大脑思维所理解,所直观,所利用,所改造,就像我们创造出的用来欣赏的艺术品,可口 的饭菜,舒适的房屋,快捷的交通等等一样。

计算机在本质上就是 过程 + 数据,用 CPU (central processing unit) 来操作 IO (input output) , 也即是用布尔逻辑操作二进制数据。布尔逻辑包括基本的 与,或,非,再进而构建出 与非,或非,异或 等复合操作(建议通过看 Wikipedia 上的 逻辑函数表示法 得知其相互关系),再进而构建出 集合交集,访问数组某索引的值,等常用数据结构的操作,最后进而构 建出万能的 函数 操作。数据在计算机体系里都表示为离散的 0 1 数字串,进而构建出 Boolean, Integer,Float,Char 等基本数据结构,再进而构建出 String,List,Set,Dict 等高级数据结构,最 后构建出类继承系统,JSON,XML 等复杂业务数据结构。

概述软件复杂性的现象

正像其他智力活动一样,在确定好概要思路后,就可以投入到具体创作中。比如创作小说,在完成相对成 型的初版后,就开始不断润色细节,以使作品愈臻完美,最后达到该作品可以达到的最高成就。

然而软件的创造却自始自终都伴随着各种不完美,未考虑周全的各种 BUG ,因项目排期产生的各种 TODO , 设计结构上的本质错误,常见的会对当前软件造成结构性更改的需求变动,等等。在不重要的小项目里,这 些缺点都是可以容忍的,而在动辄涉及到几十上百人的重要大项目里,重构是家常便饭,实在逼不得已,就 直接全部推倒重来,并在重新设计时吸取了经验教训,也会加入到下一版的核心设计思路里。在大项目的宏 观层面,会逐渐演变为 SOA (Service-oriented architecture) 架构,也即是模仿类比了现有的人类社会 结构组织。

分析软件复杂性的内在原因

如在 #软件设计的定义# 里所说,软件设计 涉及到两个方面,其一是大脑思维,其二是计算机逻辑体系, 两者关系是前者映射到后者。正如存在修补软件 BUG 这项活动,我们知道 大脑思维 是 远比 计算机逻辑 体系 丰富的,也即是对于同一事件,前者是包含着更多的信息的。所以我们也可以理解到,两者其实 是不等价的,前者比后者高级,前者需要被降格输出给后者。

所以导致的问题是如何挑选和组合 前者知晓的信息,把它们映射到 后者的逻辑里。而这里就涉及到美学 和逻辑这两个很宏大庞杂的领域,。

先打个比方, 用照相机给风景拍照,把三维的变成二维的,虽然我们知道照片指向着风景,但照片的信息 只是包含着某个三维时机里的某个二维角度,其他视觉信息都没了,当然视觉之外的其他信息自然也是不 存在照片里的。对于给风景照相这一活动而言,我们唯一可做的就是,花心思选择好构图和光线等,以求 得到一张美丽的风景照。即使是像照相这样相对绘画少了更多专业技巧性的专业,普通人拍的越没有专业 人士拍摄的精美并有更多的解读含义。

人人都知道美是什么,可是关于美的定义却常常说不出个确定的来。人人似乎都确信自己知道某个事物是 否美,而创造美却不是人人都可以的。面对软件这一首要以实用为要点的事物,接下来我会转而使用 上下文 这另一个词,即是从各个侧面去考察一个事物的各个方面是否美,是否好的。

逻辑其实是很复杂的,远比图像和故事形式等复杂,稍微有点软件设计经验的人都知道。这里我也举个小 例子用来展现逻辑可以多复杂,假如昨天是明天的话,那么今天就是星期五,请问今天是星期几?这个问 题我相信绝大部分人都不能在短时间里思考出结论来,因为我从周围人和互联网上观察来的现象即是如此。 我相信外国人也是如此,因为我在著名英文国际问答网站 Quora 上见过问题。我相信古人也是如此,我们 的身体就整体素质而言是强于古人的(即地球上更强盛的物种),而头脑也不亚于古人,更何况现今普及的 义务教育。我相信后人也是如此,因为这是我设计 Human 编程语言的最核心思想, 上下文是有限的,具体 论述还得看完这整个草案了。最后稍微说下"今天是星期几"这个看上去只涉及到三个概念的简单问题处理 起来会超出预想的复杂度呢,是因为问题里得觉察出昨今明都可能有真假,而且相互缠绕在一起,假的今 天链接假的昨天,假的昨天链接真的明天,真的明天链接真的今天,每个都得仔细识别和确认,并理解成 一个上下文(这个星期几问题已经没法直观了,除非你记住答案)。所以三个概念已经很复杂了,成千上万 行的代码如何编写,升级,和维护呢,代码之间还有很复杂的逻辑关系(比有 BUG 更糟糕的是注释文档也 不可靠)。

我也是抱着类似的信念,挖掘和思索人类思维的本质,去设计一门对计算机语言用户来说易于思维和理解的编程语言。"易于思维"意味 着方便用户在具体业务和计算机多层次抽象之间的映射,同时也包含着创造。"易于理解"意味着方便某具 体项目的相关用户之间的协作,同时也包含着传递。

理解人类思维本质是解决软件复杂性的唯一方法

思维是什么

比给出美的定义更困难的事情是, "这个世界最不可理解的就是它竟然是可以理解的", 这句话是爱因斯坦 说的。这么说的时候,我们好像触碰到了用来思考感受创造美的思维(也可以说是灵魂,自我,注意力,之 类的概念, 或者是哲学家维特根斯坦所说的神秘之物)了,这个问题已经被众多哲学家和心理学家等各种家 所探讨,我也不知道是什么,在这篇草案里我也不准备尝试去解决这一问题,因为 Human 编程语言认为这 个问题是永远也没有答案的。

上下文 作为思维本源

Human 编程语言最核心关注的是思维折射出来的 上下文,即一个感想,一段句子,一幅设计图,一组方 案,或者该组方案的好处,或者该组方案的坏处,或者该组方案的某一处细节。所以我们看到不同的事物 都可以抽象为一个上下文,甚至一个上下文可以解释为其他角度的上下文,也可以从内部剥离出一个新的 上下文。

上下文 引发出的事实

  1. 有限性
  2. 外部二八原则, 从使用量上
  3. 内部对称性 , 1, 2
  4. 易变性

上下文

  1. 上下文是人类思维的特征,比如日常交流里

  2. 上下文的例子随处可见,日常交流,文学作品, 既是优点,也是缺点。美驱动着上下文。 编程语言里。 我认为这是

  3. 上下文的定义取决于一般人类思维能力。

  4. 人们通过时间性联系在一起,即所谓时过境迁。人以群分通过上下文或语境相似联系在一起。家族的血统通过人的向死而生延续着。

  5. 人不能同时思考两件事情意味着上下文。

  6. 写完代码,但是一般来说一定不完全正确,还得调试,这就是人类上下文的局限。

  7. 编程语言设计核心要义是以相对上下文为中心,辅助以各个概念层次。应该不是基于机器学习的统计来,而是显示的固定规定。或者当前项目自身,或者经验统计。

  8. 识别不是自上而下,或者自下而上,而是整体,整体意味着注意力,即上下文。视觉从视野里分离出主体的汽车。

  9. 事件编程是手工指定异步IO,其实应该可以自动的。过程式是短期记忆。面向对象是带状态转移的过程式编程。函数式编程加快上下文切换(curry),确定性。

  10. 因为javascript只有一个CPU,所有代码是同步的,而IO不同步。假如js多进程,多线程,问题就多了,得函数式编程了。现实世界却没有问题,真奇怪呀!所以问题就出现在人类大脑的单CPU性,上下文切换乱了。现实世界对我们来说真的是个谜啊。

  11. 一切皆上下文。Human 编程语言也是一个上下文。

  12. 给一个上下文理解,而不是一堆Object。上下文就是解释。

  13. 上下文不是思维的某种形式,而是思维的本质。其驱动者是自由意志。

  14. 上下文,类,对象。复用算是什么?

  15. 区分只是在上下文内部,上下文本来就是独一无二的,否则没必要创建一个新的上下文。

  16. 上下文本身是个上下文,它也理解不了上下文以外的东西,所有上下文理论是自证的。

  17. 举例ActiveRecord的类定义里有scheme和方法等,两者可以分开为两个上下文,但是可以像Ruby传统里可以直接调用,或者另外一个关键字(多个平行上下文就看顺序排列优先级)。得有关键字来做平行定义,说上下文a平行于上下文b。

  18. VIM分屏就是展现当前编程人员涉及到的上下文。

  19. 《重构》里推荐一点点重构正是“人类上下文局限”的体现

  20. Ruby的面向对象,上下文,括号省略,block等 很适合DSL。这个符合DSL的阅读习惯。

  21. 没有上下文限制导致概念间的误解,比如函数调用开销大。

  22. 避免继承,鼓励组合。所以Ruby的mixin module在这里变为.__type__和.type("feature")。相当于用形容词实现。实现多个上下文一起思考,也好像变成了易于理解的自然语言描述。相当于存储引擎改了,可是我们就直接创建MySQL表使用,约定大于配置。这样不是一颗树继承(不鼓励太深继承),而是可以向前向后联结。

  23. 顿悟是上下文之间贯通,形成直觉的过程。

  24. 懂很多和未知原理的上下文是一件刻苦的事,所以初中对前端blocks式架构超出经验范围有点诧异,但是因为能work和并非完全不可懂而接受。另外jQuery实际上是一套声明式DSL,已经无缝融入JavaScript了,所以用户接受了。

  25. 上下文是人类理解思维的,所以是一直不可完备的,上帝的才是完备的。

  26. 概念不是上下文,而是体系,是上下文的一个直观。正想爱因斯坦的相对论公式,每一个都需要更多的解释。其他公式也是如此。

  27. 文学化编程文档注释多,代码被缩进夹在其中,其实就是上下文的体现。

  28. 每个上下文都得至少一个注释,即使是个空格。也即是“文学编程”。

  29. 美体现在内聚性,这和上下文相辅相成,包括不同原子或上下文摆放体现的美感和内在逻辑。

  30. 长尾只是因为上下文。包括二八定律。正态分布。字符频率定理。等等。

  31. 编程就是思考,思考就是上下文。

  32. 从效果出发,把次要元素去除,类似计算机不同层次的IO,从而得出定律,这全是上下文的功劳。

  33. 从上下文走到上下文,别人验收软件另一个上下文。从耶鲁《死亡》想到听觉作为说服的艺术。

  34. git commit 细粒度的上下文思想。

  35. 领域无法解释不同领域之间类比的现实。所以上下文更确切。

  36. 解释就是经验的上下文。

  37. 公司架构和部门和职位即是上下文。

  38. 好的幻灯片完美的展现了谈话的重点和上下文。

  39. 在没写完代码前,认为任务简单,正是因为上下文机制。即使明白者,也认为多花时间别人和自己就会理解,实际上都高估了。可是这附加和隐蔽的上下文藏在哪里,可否通过逻辑等手段推断出呢。答案是不能,因为上下文是人类理解的形式,形式为直观和超逻辑和美感等所创造和推动。上下文内在才是逻辑的。

  40. 通俗讲解即是把专业术语的上下文放入接受者熟悉的上下文(通常是日常经验),在一个上下文里,置换一个(或者二个)即可。这样别人就理解了。

  41. 生命才有上下文,即需要一个head。而无生命体不需要。没有思想,就没有重点,缺乏凝聚的重点,比如岩石等。

  42. 额外性意味着杂质,意外,无意义,和主体上下文的关系很微妙。

  43. GC和上下文结合在一起,可以实现局部回收。每一个上下文需要给出一个自足语义。

  44. 快速编写程序应该属于DSL,否则应该构建完备上下文架构。

  45. 长时记忆是一种上下文的记忆。

  46. 概率论是上下文体现出的另一个角度。这个世界有本质,在人类的上下文看来体现为概率。也许公式就是概率的某种极致。

  47. 限制是对堕落的制衡,对内心的平衡,上下文思考的辅助。

  48. 程序都应该知道当前在哪个上下文,比如函数内部也应该知道。这样比如递归就不需要还是本来名字了。当然函数内部的栈就对一个对当前函数引用了。

  49. REST的优势其实就是上下文吗,接口不会一团乱。

  50. 所有词法是静态的,那该上下文就是静态的。

  51. 人类语言肯定不是机器语言,因为隐含了太多经验(上下文)。

  52. 程序等价 人类思维等价

  53. 对于程序,不是部分组成整体,而是整体拥有部分。即整体大于合成的部分,其实任何事物都是这样,因为上下文总是可以展开的,待发现的。这说明了人类思维的局限和特点。

  54. 整体论或还原论本质就是人类思维有限上下文体现的两面。一面是分解,一面是意义。上下文就是时间的来源,时间联系了所有人的思维。

  55. 谈话有时比文档架构图表更好懂的原因是有个上下文清理。

  56. 时间让上下文成为可能,也让叙述变得理解。

  57. 因为生命原理是上下文,那么生命的认识原理也是上下文。

  58. 函数不属于对象,而只有当进入某行为上下文后才有所行动。

  59. 写文章用成语是加入故事型上下文,加深理解的方式。比如高中时“结绳记事”成语润色了文章。

  60. 进入另一个上下文机制,比如对象序列化,也是一种 as 模式。就好像一列座位用List的API。

  61. 面向对象里会在函数里绑定一个星型模式的对象上下文。

  62. 加 @safe 装饰器,把一个上下文包裹起来。然后要求该上下文里牵扯到的其他众多上下文也是 safe 的。有些对象虽然丰富,牵扯

  63. 提取重点这种上下文手段非常重要。

  64. 在还原论里,会导致结论就是原因。比如上下文导致了上下文。

  65. 等号会返回值的上下文,并可以体现出具体值。

  66. 刘慈欣说的水滴在小尺度上也无懈可击,只是因为人类上下文理解还没到那个程度上而已。所以应该还是上下文文明。而不是上帝文明(另外的)

  67. 一般意义的函数和上下文概念可以玩出闭包和惰性求值等高级玩意。

  68. 数据没有上下文,因为它们待思维去解释。而代码就是思维,所以有上下文数量限制。

  69. 限制上下文七个实际上是强迫用户做减法和归类。

  70. 不是说世界是由上下文组织的,而是人类认识是由上下文组织的。

思维有什么用?

思维给我们带来了两件东西,其一是上下文,其二是美。

思维的局限性导致了多学科的出现,也即是人类社会的繁荣。

  • 人类思维用语言来表达,因此语言体现了人类思维。编程中的例子可见 "Context"。

视觉

  1. 视觉是美的,原始的,自然区分上下文的。

  2. 人眼如何把大千世界尽收其中?人眼分辨率? -> 视觉最靠近大脑,会被大脑自动分辨为有意义的上下文。

  3. 单词由字母组成,可是阅读时就忽略了,而着重于意义。所有视觉有自动识别的肌肉上的特征。

  4. 编程让造物主从对象自身设计,七个器官,五个手指。而使用量和效果也是依据二八法则,比如人类依赖视觉远多于听觉触觉嗅觉等。大拇指和食指的组合占据了大部分。

  5. 眼睛视觉和思维视觉,孰先孰后。

  6. 视觉,听觉,触觉,嗅觉,味觉,空间感,思维自我。一共七个。短时记忆为七个。

  7. 长时记忆是视觉,短期记忆是听觉(156页)。我和女朋友出来,记得路上发生事情图景的前后次序和细节,至于听觉,只有特别印象的才有,比如服务员问我点了什么冰激凌。想想昨天和连华俊晨聊了什么,只有零星的整理概念,比如音乐爱好,点菜细节。短期记忆是听觉可能就是因为我们生命的时间性。 所有难以维护和理解的代码是听觉记忆。好的是视觉记忆。之前我把编程比拟为绘画即是如此。

  8. 可阅读的文字是视觉和听觉的结合,短期记忆和长期记忆的结合,考验人脑思维组织的技艺。

  9. 连华说我的内存小,理解周报告家长端。因为我和别人沟通经验不足,更多是视觉思维。别人是听觉思维。所以在长时记忆里我胜出。

  10. 符号编码连接视觉和听觉。

  11. 建议编程都切换到更有利的视觉模式。

  12. 而创造力和视觉听觉模式无关,我还没有想。创造力是在一定时间里专注才能有的。

  13. 听觉和视觉唯一可以相互转化的只有符号。

  14. 视觉有模式(思维会从中找模式),而头脑里的一堆概念无法找模式,所以有数学家用图像思考。

  15. human虚拟机执行和Luigi类似,有向无环图。当然也一样可以做视觉化展现,无论是当前项目还是整个VM。其实就是命名空间。

  16. 思考快速眨眼,可能是来自远古需要细察周遭环境而进化出的特征,依赖于视觉模式。或者思考时看着空白的天花板。

  17. 爱因斯坦文集一。567页。《关于数学领域的创造心理》。他用视觉和动觉,用肌肉。语词出现时才纯粹是听觉的。所以编程和敲击键盘一起才变成听觉的,这个技巧很难把握。编程提前思考意味着视觉更多。

  18. 视觉编程应具备符号DSL的能力,譬如函数式语法,所以符号在可视化上很关键。matz最近设计的streems即是。

  19. 肌肉记忆,视觉记忆,听见记忆,三者在思维中混淆。常见于游戏中。

  20. 视觉站在思想前方。

  21. 梦的无声即是证明大脑以视觉为主。补: 换到梦里去了。

  22. 现实世界是美好的,眼睛耳朵即是。而大脑唯有由美指引,才能领略世界本质。所以大脑思考可以尽量降级为视觉,而非听觉,以便于沟通。

  23. 耳朵不可以关闭的原因是鼻子,触觉等更低级的也无法关闭。只有视觉的眼睛才可以关闭,因为其对大脑思考影响最大。人的大脑被封闭在脑壳里

  24. 甲让乙计算五加七等于几,乙先是耳朵听到,传入到大脑里,在大脑里用视觉浮现出六和七两个符号,然后根据肌肉记忆,计算出是十二这个数字,最后用嘴巴说出十二这个数字。

  25. 视觉影响大脑思考,故用下一层的听觉来全方位地作为大脑思考和沟通的顺序。

  26. 人在大脑里对名词有想像视觉,是因为有经验,比如马,或者组合出来的龙。但是却不能想像灵魂,因为没有视觉经验。或者“有”这个词也是不能视觉的。

软件工程

并发好像和语言无关哦。

lisp遵循human是否可以,还得学会lisp再说。

闭包的本质是把数据(类)的地位让与函数,,也是how让位与what(how必须通过数据改变来体现,而what只是表达了一种声明式。

一切都是逻辑,数据是,函数是,区别是数据是被动的,函数是主动的。另外,函数因为数据而显示其自身,当然就计算机表示而言,他们是均等的。

代码不应该拖累讲解速度。即脱离代码给别人解答具体相关问题的速度,结合代码讲应该更快些,而目标效果就是对方可以维护这相关代码。

敏捷等方法论,程序语言之争,项目工程管理,都已经成为宗教。而问题的本质就是人类思维,我觉得还是和人类思维本事死磕更好些,与自己和别人死磕。所以有句话说,问题的本质还是人。

因为计算机完全可以被人所控制,所以其中的“时间”也是被控制的。但是当人类面对其他未知事物,比如外太空,那必然得先抱着敬畏态度,并随时准备接受颠覆世界观的可能性。

函数(即过程)和类可以合并为一个概念,这点参考JavaScript。

可选。类也有版本的概念。包括其中数据和行为。

软件工程毕竟还是一个完全在人类日常经验范围内的。

UML 为什么失败?!http://www.cnblogs.com/shuhari/archive/2009/07/01/uml_is_failure.html

编程语言依赖的作业环境应该不依赖于 编辑器或IDE。

互联网快速开发实现是以牺牲远见为代价的。

链接后的语法树雷同于Human编程语言,但过程和结果还是值得我研究。

explain编程语言。编程就是教一个傻子做事,不断的解释。

DSL的伟大之处就是在于单一职责,局部性,以及线性故事性。

对计算机来说,talk is explain.

human翻译成Python代码,就像CoffeeScript翻译成JavaScript一样。但是得注意是否可以一一映射,而且Python是否优点够齐全。JavaScript主要是事件驱动太强不合适。

talk is cheap,show me the code。意味着核心思想可以剥离,最终结构的生成以及平衡等都得益于功力。

linus 指的数据结构及其关联比算法重要其实是针对 数据持久化的项目来说的,也许不完全是。

Linus 说,计算机科学和物理一样,都是在一个非常基础的层面,探讨整个学科的运作原理。66页。

在有经验的前提下,审美是首位的,敏捷和解决方法的出现其次。和晓光讨论JsonUtils.unicode_dump有感。

我始终觉得不必完全在意别人的看法,只要自己觉得可以相信自己能领导自己就可以了,而不是把全盘把自己交给整个社会体系。

群体智慧不是投票,而是每个人都有自己的主见。

在项目的不同编程阶段,人是会遗忘的。对概念和概念关系加以拓展和进化。这也类似于众包的维基百科。

我有这么多开源项目,以精简复用的形式表达。

对一个编程低手说,即使你的程序达不到优美,但至少应该清晰。虽然清晰和优美同样难。Java是否完成这一任务呢,没有,在犯错上强制了点而已。

Java的强制异常检查错的地方在于不能把它和其他东西分离开来,这样是一种混乱和干扰。所以我更期待可以在任何层次和区域分离的模式匹配。

前端在于它的被限制性,重置性。按业务场景(人类交互)分离是很正常的。前端更像现实世界,服务器端只有通过各种接口机制更多,即数据。很少直接去操作服务器内部细节。从业务整体角度看,它只处理了前端部分。静态页面由后端处理逻辑,单页应用则承担半壁江山(中学题库)。

被项目后来者理解,代码必须转为长时记忆模式。

CPS和human编程语言。human强制数量,可能得引入CPS。

函数式里用CPS递归方式实现for循环,避免变量赋值或重写。

代码最好具有不细看也知道做什么用的特点,适当的注释和布局。

和一般编程语言有一样的Object基类,但是名字换成Context。属性可以任意多,但是行为最多七个。考虑一下原型继承。

声明式的SQL是一套限制型的逻辑范式。

二分查找的递归是生成新列表,迭代是范围值缩小。

human的包机制和python的import语句应该差不多,但是托管机制还是和ruby和node类似吧。

Context也是可以run的。是否参考Python用两下划线表示内部呢。这样就支持函数式编程了。

Python里的关键字class和lambda,在这边都用context表示。没有Context,所有默认继承于此。或者和Python一样有没object都可以,但是会少了object属性们。如果是Ruby,所有都是Object,加上面向对象,那就可以方便进行5.week.ago这种链式调用了。

python的__slots__设计如何?

__type__里包含了默认属性,所以这个是在另一个context里定义的,没有就用默认的。

__type__赋值的是String,比如“list”。

一个Context可以有多种__type__,这多个types的数据是相互映射的(说错了,大小整数就不可以,只能说一部分可以转到另一部分而不会发生改变),既可以一一转化,比如最简单的是Array和List和Stack。但是它们之间函数个数和名字可以不同。

自定义类比如表示一个长方形,宽和高,惰性属性面积。

函数和数据如何转换?Python有property把函数转为属性。

Python做错了,点就表示调用执行了,如果看定义,比如通过__dict__看本来是什么,或者从类里面看。我刚从Ruby转过来接触Python,对方法必须加括号才能执行表示不适应。

动态属性如何实现?Ruby里有method_missing。直接定义一个__missing__属性函数。关键是这个missing也得由context实现才能统一概念。

__type__就多了一个概念啊,在继承时无法指定哪种Array。todo

每个context有一个HTTP URL地址。

Ruby语言的缺陷,缺乏命名空间,这点Python好。但是Python的类和实例没用大小写区分也是遗憾,当然一个类new之后也可以返回类。

异常的本质是,是可以预见的吗?!

和人类社会和个体一样,一个事面向一个主体。虚拟机审视代码逻辑依赖启动,如果没有并发,就等价于传统单进程执行。执行流程可以被审视,在human里,和Hadoop等分布式一样,可以把一些动态context注册,即是它们会出错,有栈。而一些很固定的,它们不会出错,出错也是它们可以预见的。会出错的就得注册。

state monad

for循环在七个限制里结构优先。

json键值并列赋值就是扁平化,但是也要考虑内部的上下依赖。

遗忘测试。在三个月后看代码。

"类“正是一种模式识别或匹配。

形容词用Ruby的symbol表示,其实也是类似于协议,但是也包含实现。

限制性的明确解释。

可以多于七个,但是必须使用序数注解。

为什么可以修改IO而不能修改CPU呢,因为修改了CPU即是把CPU当作IO了。

@ 既是 doc,也是 decorator。

Ruby里的module加上限制后其实就等价于human里的形容词。

在human里体现丢弃的概念,即封装成某一个层次,机器码,字节码,程序代码,等。但是现在语言只有程序代码一个层次,否则就得多语言混用,比如Ruby的C扩展。 其实不需要这么多出错栈,只要对应的局部即可。

loop实例化,并变成闭包。while同。

每个context里最多包含7个context,除非序数编号。loop,while都是context。

形容词变成symbol,这样不必引用类了。在参数传入时限制行为。

代码排列应该尽量交给编程语言,可以自动检测的。

组合 前面其实也需要.的,但是如果是语句开始,一般就省略了。或者是homework..day_limit.days.ago. 。找个更好的例子TODO。

不要关键字new,而是 book1 = 1.Book(name:圣经)。这样更符合日常直观,而采用的是组合模式。

for 循环等 其中的变量名必须以数字结尾。

于是类名是否支持复数形式呢,我认为应该在 组合 这一层次上解决,纳入标准库。复数其实不强制。

取消继承,和Haskell一样(待确认)。最初随意指定一个对象就是Nil,即从虚无中来。当添加一些东西后,比如组合,就不再是Nil了。

@表示装饰,$表示资产。

软件架构正是慢速思考的体现,思索每个角落,灵感出一个方案。

程序员三大美德之一暴躁是因为设计程序需要集中精力,外人不能中途打扰。

on关键字替换,loop,for,while 等。两个for循环,第一层两个变量,第二尝遍历第一层第二个变量,并和第一层第一个变量相乘,得到一个总数。

如果变量仅在一处作用域使用,推荐放入该作用于。或者该变量是外部某一对象的属性。

字面量均通过.结束来返回具体对象,字面量仅仅作为概念,但不是对象。这样通过组合就可以了。

method作为公用函数,而len才是Array方法或属性。如果是类似Python的__dict__也应该用公共函数取。可理解可读可划分永远是第一位的。

首先明白在管理依赖这个业务里,编程比UI强大,UI是由编程API构建出来的。所以两者不矛盾,也不存在难维护的问题,唯一区别是UI比纯粹编程多了可视化操作的功能。

调研 DHH 是如何写 Rails 的。

框架是从业务中逐渐抽取出来的。即是不能脱离具体业务,就直接写出一个能通用和完美解决问题的方案。一般而言,软件架构师是在完成具体项目时,就顺手完成了一个框架。或者换一种方式,框架的测试(包含测试业务案例)也是跟着业务开发的。 所以软件架构师带头写代码是必须的。另外还有几种架构师,技术架构师是对一种以上的技术体系非常熟悉,而且能和业务结合起来,这可能不太写代码。运维架构师,项目经理就不说了。

任何框架(包括编程语言)都有至少一种核心理念,且是内省的,即是指导的原则,也是逻辑结构。

鼓励使用组合多过函数属性,组合其实在二元函数上又多了一层内省结构。

函数只是代码的数据而已。而且应该是有能力向外部提供各种细节。只是数据的上升而已。

context是value\,order list 等。

私有方法,抽象类,全都离具体业务太远了。只是为了表达结构而存在的。

虚拟核,虚拟进程,用消息命令,黑盒,模仿人类指令。

函数或方法在本质上就是两两组合的形式,其实在自然语言里更多才合适,也容易被思维理解和操作。

对称性在语法上的体现。_.序号等。

一边是组合式,另一边是函数组合,这样对称性。

8 / 2 其实是 8./.2. 的组合式的简略写法。即 / 隐含了 ./. . 。这样不要面向对象,而是 [8 , /, 2] 共同组成了表达式,缺一不可, / 后面必须跟着一个数字,而不是歪着理解为 / 是 8 的方法,2 是参数,太费解了。

(3 / 2) * 3 这种就得强制加括号了,因为没有 / * 这样的模式,除非自己定义。所以展开是 (3./.2.).*.3.

一个是 Context \,相当于通常的 class。另一个是 Bundle,相当于通常的 module。Bundle 即是函

在组合式里,加个括号表示引用的是对象。可是这样参数如何传,还是前面加个一撇呢。

一个变量既有代码结构,也有求值。

函数的本质就是改变输入为输出吗?那函数式和命令式本质区别在?

除非性能,否则正常的直接推理相关业务逻辑即可。

类可以多个别名,这样就支持2.Books 返回一个列表了。

用 =: 表示依赖变化 求值吧。这样可以表示for循环中值改变。

类方法或者静态方法,用组合式就足够了。

human语言不是继承模式的。而是组合模式。因虽然是像Ruby 一样include module \,但是其要求符合默认不超过

对象不仅仅是值,它们会体现为值。也即是人们看重的价值。

函数是数据的运行模式而已。静态语言对于这个限制更大,因而看上去更底层。

根据 @safe ,我们就可以把某些上下文编译(优化)为纯二进制执行文件了。

函数应该是可以序列化的,即使牺牲了空间。可以和js类似,这样不用管外部变量。

如果要实现可改变的,就用另外形式的。这时值其实算是求值的,并且应该携带相关信息。比如:changeable Item :=

erlang的函数多版本其实是符合自然语言理解方式的。比如登陆,可以只有用户名,可是还得兼容用其他登陆,比如加年龄地区以区分重名

_和.这两个符号是必须在语法设计时融入的,因为它们足够低调。

不管是面向对象的对象加函数属性,还是函数式组合,都逃不出二元论基础,而缺乏组合式。

编程关键,concept\,aspect。

赋值用 := 表示,如果里面变量是可变,就加个前面一撇。类似于Haskell和Lisp。不过还是觉得所有变量的赋值都是一经赋值,

Human 里尽量分离数据和函数过程。

一个程序运行起来后,不同服务应该是消息沟通, 类似 Erlang。

鼓励使用组合多过函数属性,组合其实在二元函数上又多了一层内省结构。

如果一个人会看菜谱做可口的饭菜,那么TA就应该可以学会一定程度的编程,分析,步骤,逻辑,优先级,主次,等等。

. 和 空格其实算是等价吧。

Human 语言的hello world 版本。 print."Hello world.\n". 内置组合。

程序内部尽可能分离。系统层面的模块化,像SOA。

像 Lisp 括号来括号去简直是反人类的。

谁能一下子说清 C 语言里运算符优先级。

=/= 这个符号作为模式匹配不错。其实根据组合里的是字符串,就可以自定符号啦,所以各种颜文字,-_- 什么的。

我建议学过编程和想了解编程的人都看一看。

使用组合式后,原来的对象只有数据了,函数剥离到组合式去了,并通过输入输出绑定。

Context是全局共享的,如果冲突,可以使用 Model(ns=other)解决。另外代码是必须放在隔离的Package 里运行的。如果是单文件等没有包名情况,则会随机一个,类似main。

函数也是数据啊,也可以被序列化。至于绑定的闭包值,和实际函数代码,当然都放进去啦。

上下文里也可以有函数属性,默认上下文事当前文件,文件命会作为包名,和java和python类似。使用某些函数组合式,导入即可。遇到组合赋值,函数就自己吸附上去。当然,上下文自己也可以覆写引用,即是有作用域。

[ ] 赋值变量其实就是创造,就是新上下文。

[ ] 组合式其实就是省略了函数名,通过参数确认唯一函数了而已。当然,也可以是有函数名的,这就相当于完全展开版了。对,省略写法而已。

[ ] 组合式其实也和 Lisp 的括号也非常像。

[ ] 代码编排的规则限制和REPL是两回事。

[ ] 数据表现为分类结构,函数表现为依赖结构。

[ ] 函数也是一个可持久化上下文,里面有source code。

[ ] 并不取消类和对象,而是取消 类不能new。以及类方法等。

[ ] 函数的序列化方案和问题。

[ ] 讲解为什么不要修改烂代码,直接重写它。

[ ] for循环也和loop一样,支持break等关键字。也是YAML,除了关键字键break等外,也只是函数,以可以抽象组合,同时也把for循环变成可操作对象。

[ ] 代码运行正确结果只是生存,代码写的容易理解才是生活。

[ ] 如果loop和for是结构的话,其中几个函数属性,那么就很容易包装和重写了。

[ ] 最完美的语言,完全为表达服务。数据结构声明里也有$表示递归结构。

[ ] human 第一个实现版本先为 js 版本,用以解决 javascript 里的问题,这样用户最多。

[ ] 禁止拷贝代码可以这样做。拷贝代码一般是函数,即一个函数库,(虽然在 JavaScript 里函数套函数的),那么只要函数足够大,比如十多行,那就检测其不要复制,推荐其封装。

[ ] 函数内容是作为延迟执行存在的,而其内容是会关联到外部的,所以也是一种惰性依赖声明。

[ ] 既然代码是逻辑的,CPU也很快,为什么就不可以很快的分析。

[ ] 憎恶过多的缩写

[ ] 变量加上1,2,3,4,..,正是我们在自然语言里表达层次结构的做法。

[ ] $= a + b + `c ,就是 hold,把任务声明后交给别人了。

[ ] 程序的作用块是可以脱离的,即一个文件里的个别语法错误不会影响到真正执行,除非调用。这种方式的实现依赖于最小作用域。

[ ] C和Lisp相当于原理,可是却解释不了人类语言,人类思想,大概就是这个上下文类比。

[ ] 依赖求值意味着要被循环或递归驱动,那么human如何表达循环或递归呢?

[ ] 继承劣于组合的原因是带来了人类不擅长的深度维度。

[ ] 参数代表函数,正是相当于分离出隐含的上下文。

[ ] @表示实体,即在YAML类定义时加下就可以了。如果link或内含array什么符号表示呢。

[ ] 组合式和函数定义分开,有利于用户去构建DSL。

可以两格缩进,也可以四格缩进,缩进只在 当前文件 有效,取决于文件的前面部分是用的几格缩进。

"##" 之下缩进的块是文档

"#" 表示文档,"$" 表示数据结构, "@" 表示函数, "%" 表示组合模式。

数据结构的操作,还是尽量和函数分开。其实这等同于通常编程里理解的 IO 依赖。

组合模式,一般就意味着其中必须有一个名词。

数据没有方法。死的和活的应该是截然分开的。

如果我的开源作品大部分的技术细节和架构都能够看懂的话。有些面试官不问技术,有些是精明,有些是含混。还待细究。

[ ] #init , #compute, #result

[ ] 1.Book替代new Book,表示了把创建一个或多个对象放在同一位置上的尊重。

[ ] 有了 |> , 就可以取消 while 和loop了。

[ ] SQL简洁的原因是内省的数据流,而且没有四处引用。

[ ] 编程语言和自然语言的区别是,编程语言是死的,而自然语言是活的,前者依赖于解释器编译器,后者依赖于人类大脑,而人类大脑思维几千几万年不变。

[ ] 上下文没有函数属性,那么就必定强迫使用组合了。

[ ] Shell就是组合模式,加文本管道。

[ ] 其实while和loop是同一个,可以相互表示的。loop是while的超集,只是while把跳出判断放在开始固定位置了而已。

[ ] 计算机并发的本质是逻辑并发,或者曰并行。针对产出而言,所以往往是 IO 并发。至于其他 IO 依赖,传统上也是一个进程搞定。或者像一般服务器架构,分离出队列和处理等,这样其实不需要在语言层面并发。

[ ] 全栈工程师不能说写简单的涉及到全栈就称为全栈工程师了,在我看来,亲自写代码和优化代码的架构师级别才算是全栈工程师。如果对自己的用到的技术做不到了解,那充其量也仅仅只是技术消费者而已。

[ ] 编程语言的问题在比如 hadoop 大的框架里会带来更多的偏见问题。系统太费解。

[ ] 函数上下文的self,this,通过组合式解决。

[ ] 当属性和组合发生冲突?默认属性优先级更高,而且一半静态数据类吧。

[ ] 单例的别扭就是在于类实例化是个别扭的概念。

[ ] 研究Alan Perlis的algol,SICP里序言说的很好。

[ ] 衡量一个编程语言是否更好,就是找不到第二个比它表达这种业务更合适的了。如果标准有歧义,请以人类思维和自然语言为准。

[ ] 1#变量。表示循环层级。

[ ] dirty解决方案取决于是否是相对永久性的,一般我用的是后者。

[ ] 程序是上下文组合,自然语言也是上下文组合,两者区别是前者是死的,和逻辑绑定在一起了,因为上下文只能照固定规则流动。而自然语言却富有千百年的诠释能力。

[ ] 程序开发不是递增的方式,那等于什么也没说,当然是一步一步开发啦。正确的是,程序开发是以上下文的方式开发的,整体是一个上下文,各个细部都是上下文,在每个上下文里思考和编码。

[ ] 函数内部有编号,这样可以动态插入代码。编号是很重要的,可以被增删改查。相当于函数中函数。

[ ] 1#hello, 2#world 也是合法变量名,用于层次化区分.

[ ] 模块化这个术语不错,可是有点苍白,没有揭示模块之间的联系,因此上下文更加合适,把我们所处的问题切分成各个层次的上下文。

[ ] 流来解决并发问题,其实就是排队,统一交给一个人处理,分离读写权限隔离。本来就需要花时间处理,隔离,加锁,这已经是最小代价了。

[ ] 编程语言学多是好事,而不会混乱,这样就只会用各个语言精华的部分。

[ ] 可以获取某对象的折射描绘,比如属性太多就分类一下。可以作为系统函数而实现。

[ ] 太多人喜欢满足于粗糙的解决方案,比如企业级开发的多子系统http通信。业务之间加隔离是不佳的,在模块层次上解耦更有力。

|> 其实也是符号。而且要求左右遵守协议。

情感, 哲学, 逻辑, 艺术, 脑科学

情感是一种时间性。比如广告的持续投放对客户的洗脑,时间长了就接受了。而图片认识了就认识了。电影关注故事的意义,看完了就不想看第二遍,音乐没有显示的意义,所以可以买听不厌。经典优化可能也是。唯一是故事不要重复讲,这是最接近大脑思维的,很容易疲倦。

编程是思维的跳跃组织。

男人脱发睾丸酮软件开发。

代码写的像PPT

图灵测试自证的反驳。

发音是语言的回响。声音永远让位于图像。

程序表现是空间性的,而运行却是时间性的,很多人被思维运行方式而把程序写成时间性的了。复制意味着静止和同步,思考和写出的程序都是。

编程就好比教傻子做事,结构化编程非常有益。

mind是创造性的来源,也是毁灭性的来源。

编程是让人的思想在外部执行,当然执行规则得符合外部载体的规则。但是编程也仅仅是人类思维,它根本不是别的什么。人于外部确切沟通的方式只有逻辑?!或者只有逻辑才是确切的。

人们之间相信理由,这个缘由是什么呢?!

同步编程就逻辑而言相比异步更简单(在多个事件之间要显示分离IO顺序),所以大脑会倾向于先忽略同步带来的CPU和IO之间使用率不均衡。

而世界运行的本质呢?可能得求教于物理或者哲学。

你不能根本了解世界和自我的运行本质,而只能经验型的接触。

维特根斯坦《哲学研究》第二页说的“拿5个苹果”在大脑中如何理解这句子里的三个概念“拿”,“5个”,“苹果”。而逻辑只在句子中,不在句子外,所以这三个概念机器理解不了,只能被定义着去模仿。

要求在一个段落里识别“too young to die"。假使 to 的 t 倒着了,因为已经识别了"too young",概率很高,所以大脑试图纠正 倒着的 to ,以使其满足答案,这样其执行行为就超出了原始需求死板的定义,转而创造性的去发现其中规律,从而达到目的。

从人为什么写作,到为什么必须得编程让计算机接受命令执行。

不只是逻辑,还有美感。

人的思维几千年,几百万年有进化吗?好像没有。

人类说话类似于机器码执行,任何人的表达于TA当时的判断在速度上于TA的能力是最快的,但却可能不是最符合对方的接受执行能力。因此,人又是可以判断对方接受能力或层次,调整自己的表达。 非也。人类可以正交或重复组合各层次概念,以补全对方的理解层次。

维特根斯坦在《哲学研究》序中把札记比作风景画。

人类思维本质在于它是当下的,它是被神秘力量驱动,而自身却不知道。不同人类思维之间只有通过感官沟通进行交流,而本质都是为了维持神秘力量的沟通需求。

具备改变能力的思维生产和消费行为,所以世界是行为主导的,函数式编程把持久化数据弱化为内部状态。

时间是人之间思维得以同步的方式,比如约会,上班。

意识区分出内外。

当面对达芬奇的油画蒙娜丽莎时被要求说出第一感觉,众人按自己审美反馈说神秘,微笑,端庄等,不过数个形容词概念,它们都是一种综合。当面对倾倒出的垃圾桶时被要求说出感觉时,无从规律而言,只反映说混乱。

发散性思维要求对日常经验的思维过程涉及到的概念进行审慎。

医学不可能根治是因为疾病和思维一样,是本质性的,是一种人类无法理解的驱动。中药西药只是从万物关系里调剂而已。所以比如心理问题是本质的,引导为主。

《时间的观念》P168。柏格森。时间意味着创造,意味着对历史的回顾,意味着调整,意味着审美。当代计算机程序的自省依赖于创造人的调整。所以可能还是得归结到自由意志的问题。

现在意味着自我。

目前我对编程本质的体系化可以类比于古希腊哲学的开端。

费曼,总想逃避,这一章,讲了大脑和身体探索。

思维是内在联系的,比如网状的,如果意味着神经细胞消息传递速度,人类体能是类似的。

语言是思维形式。编程语言阻隔日常思维,专业领域,这个事得弄明白。

计算机可不可以实现,意味着可否映射和复制,比如硬件API。情感无法映射,所以替代不了。计算机无法替我们吃饭,做爱,大便。

因果关系意味着简化,来自《逻辑思维》活得明白。判断意味着主体,意味着判断。

梦里用的是另一段记忆区,所以梦里还有以梦。

人的精神本质在DNA里吗?

既然大脑分多个区域,那为什么人基本只能同时想一件事情呢,除非变成躯体运动。

人的理解总是合理的,所以理解存在是好的。

世界不是真这么简单,或简洁,而是一定要在这个领域层次理解的话,定义出来的规则只能这样。如果规则还能解释或预见更多事实的话,它只能说明理论到目前为止还是可靠的(只能在自身理论里自足),但是却无法解释更多理论外的东西,比如相对论介绍不了物理层面之外的事物,如音乐,艺术等。所以人类的本质和未来就是内心而已。

为什么你的个人大脑占据的这部分空间必须可以理解其他所有空间呢,包括与你类似大脑的许多空间。理解是大脑的独特机制。

我的朴素直觉,别人的系统知识,并没有本质区别。

生命和思维之间的关系。狗是如何识别出主人的手,而不将其吃掉,是因为经验和遗传吗。

计算机模仿大脑架构。一切都是源于模仿世界,挖掘意识的背后。

小说的艺术在于呈现什么,古时不带凸显主题组织的流水账。侦探小说在于整体,一个一个抖包袱,包袱包袱相互串联,最后形成整体,真相大白。

解释给别人听,意味着短时记忆,即听觉。但是东西一多,杂乱,就不行了。

在大脑为解密之前,如爱因斯坦说,不可理解的在于它是可以理解的。

美好食物虽然与思想无直接相关,却是思想的养料。

康德哲学难读的短时记忆?

创造是长时和短时记忆的混合。讲故事是长时记忆,可能是。

伟大的作品,就风格来说,必然是个人的,就实用来说,比如是世界的。

性感的Human编程语言。应该是。

短时记忆的创造只有变成长时记忆模式才能被大众接受。

编程更多在于长时思考,所以敲键盘是不需要快的。

长时图形记忆是短期的整合,升级版。

大脑和大脑不能融合,意识不能直接对话。意识的本质,存在,自我,保存,海德格尔的持存。自我真的是个谜。能想象大脑可以融合吗

对我们来说,对大自然进行改造或破坏,对于自我是没有影响的,主体和客体。

说下自己教育背景,退学等。

阅读尼采,仿佛参观一个疯人院。

听音乐的身体颤动共鸣源于音乐的易逝性,生命消逝短暂,死亡恐惧。希特勒演讲。

当自我遇上了自我真是麻烦,遇到他人时因为自我的单CPU性才能保持一个自我。

梦是被四处乱扔的记忆或经历。睡眠时,大脑CPU回到梦区,所以重复梦,或者潜意识最近在想的深刻,渗透到梦区。可以看看睡眠时,大脑哪些区域还活跃着。

计算机的抽象和我们展现了人类的思想可以有多少抽象层次,和物理学等学科有多少类似,但是其根基确实逻辑和二进制,而科学的根基我们却不知。或许计算机的根基是思维本身,而思维的根基就是另外的哲学神学美学问题了。

代码即你的思想,所以没有重复。

口腔溃疡,眼睛,身体累,上班远,明白人生。

晓海,架构师,讲给我一样明白。

human编程语言关键字“what,why,how”?后面加说明字符串?注释自动匹配到最相近的代码,如相同则警告。

内省。statlysis,阳光书屋。

连华适龄数学教育,人思想在睡眠时不一样的,用脑电波对大脑的数学部分进行自动训练,就学会了。

听一般主题演讲,听众觉得很有收获,大部分人是总结了大概和个别句子,专业人士会两方面更多。原因是听觉记忆导致。感染力是听觉的艺术。

可以说出混乱的标准,超过六七个,找不出模式,却找不出美的标准。

过多使用听觉记忆,长时间编程,导致脱发。而设计师不会。

human编程语言版权?

听觉记忆正是上帝模式,所以所有创造性来自于顿悟。图像只是助于理解。但是人不可能随时和换人去达到上帝模式。

音乐,即时记忆,激动。绘画不会。

在ruby聚会,吕神和另一人反对一定是确切的七个,说不应该阻拦。

数学是人类理解里属于看上去简约的一类知识,所以面对数学无穷问题更容易暴露出来,事实上涉及这些都是不可能穷尽该问题的。唯一可做的是和叔本华说的一样,在审美创作中麻痹度过,无法停止的欲望,直到死亡。

turing说,“合理性的证明依赖于人类记忆的有限性”。

中文房间很扯淡,汉语和英语在一定程度上是可等价的,而且背后的思维会去引导和意会两者联结。

《图灵的秘密》330页。约翰卢卡斯说机器容易计算,但是不能运行元数学。元数学没有定义哦,我认为他指的是思维。

形容词可以展现对象的多面性。以及思索的更多可能性,挖掘其内在未知。

细节局部都懂,难懂的是整体直观。

科技的显式力量尤为强大,就像男人力量大过女人。

编程本来是数学优先的,可是在实际做事上还是听觉记忆占优,所以命令式为主流。可是编程大师已经融合函数式+命令式+。。。了。

理解就是变成直觉?! 然而直觉是可以遗忘的。

人脑里的数学计算其实是图形化的直观。还有训练为肌肉记忆。

思考是用短时记忆来处理长时记忆,短时记忆是用来被遗忘的。

数据是用来看的,逻辑是用来理解的。

人类的解释是最迷人的东西!

直指计算机科学和编程的核心问题!

方面,层次。横,纵。

如果精妙算是代码之美的话,那什么是精妙?

面向理解编程。

上帝关注显露,人类关注理解。

《没有时间的世界》,他们三个借由对思想与实在界的设限,来体现出时代精神与当代思潮。

美好的事物是各种感官都可以感知到的。比如一个美好的房间,你可以想象到味道。超越感官的。

训练抽象思考。主动发现美。

因为语言交与别人理解,所以说得必须可以被理解。而程序不尽然是,只要有限严格语法对即可。

人类世界其实没有继承,继承是思维构造出了的,抽象了事物。其实现实世界的进化是组合和创造而来的。

时间的共时性是不是等同于人类理解?

得到确信就是理解。

触觉感知形状和温度。

human编程语言作为整体和01逻辑并不等价,虽然运行于之上。但是就像油画和画布不等价一样,人解释一样的才是等价的。已经差的太多了。

可视化理由之一:俊晨grep的数据源出错。指错了。

类本来就是抽象的,所以何来类方法的意义。所以应该取消类方法,类只用于组合。

组合的模式定义不需要动态化,因为其本身就是动态的。

思维不等同于语言的简单证明。感受到美,却无法用言辞表达。词穷了,但在思索。

程序语言是用来描述思维的,人类语言也可以用来描述思维,所以人们在思考等价性。不过人类语言可以辅助程序语言。

编程语言的核心从思维出发,其次需求,逻辑,美学,等。

人工智能的矛盾在于,加入有了人工智能后(即和人类一样智慧和情感),那时候还需要编程吗。核心就是人类的思维即是需求和存在,没有人类,智能就毫无意义。

人体对称性是神的智慧的结晶。和体现。

代码和缺点一样,自己的远比他人的能容忍。甚至自己缺点也要怪罪对方优点。

创世不是无中生有,或从凌乱无序的物质中制造出事物,我相信是生命的物质致此。

成熟的人。理论体系。创始人,老板,leader。尼采超人。

机器是可能出现智能的,但是肯定不是逻辑的原因。

狂妄的人最谦和。

我并不觉得自己羞耻,因为我本身就是人类的遗传。

AppleScript的缺点是其自然语言风格过分压在了不适合快速浏览的听觉记忆上。

编程是通过关系来描述需求概念,所以囿于逻辑。而思维包含一切。

欢迎贡献包括:Batman等各种。

女人一定不喜欢和只懂得相对论的物理学家谈恋爱,而一个她想要谈恋爱的男人恰恰懂得相对论却是十足加分的。

还原论的弊端在于人们只能认识,不能改造。中西医区别只在于是否严谨。发现关系是可以被利用的,也即是技术的解放力。

一切产品都要尽量和人类直观和日常经验和需求领域保持结构的一致性。

风格是通过“动”来揭示的,一个作家的文风,建筑风格,菜味,兼在时间里知晓,风格表现为一种体验。

在学习编程前,先了解美学。

爱不需要矫饰。所以是力量的源泉。

大脑清醒的机制是什么,比如睡醒后。

人类语言的模糊性嵌入再精确的human里。

现实世界不会乱,而编程会乱,是因为在不加控制和限制的脑中。

世界的内核便是存在。人类活不过三代。

不过大家应该觉得无知才更狂妄吧。

图像与意义,以及淡忘。

目前科学的局限在于只是利用自然,而没有在原理层面改变事物的本质。

我认为人工智能和外星人很可能在本质上是同一个问题,即它们都是不存在的,人类太孤单了,智慧太孤单了。

由于二元逻辑的限制,导致程序员在理解事物上更容易木讷。而医生作为直接面对最终客户的职业相对会好些,程序员木讷症结在于当前程序员思

讲故事,浮现出想象图像。

晓光说原始人住在山洞里,已经看不见了,所以得借助耳朵来识别潜在危险的野兽入侵。但这是事后的推理,在野外面对野兽时,还是眼睛捕捉的

研究一下函数的本质?

正是语言的二元布尔性才使得图灵完全的语言的语言可以 debug 。而 SQL,CSS 等就不行了。

人类语言被计算机语言宽广,而人类思维比人类语言更宽广。

逻辑就像地球重力,虽然我们时刻受其束缚,然后我们日常却不必太花心思在这上面。

[ ] 空间为什么有三维,是因为心中有三维。彭加勒《最后的沉思》。受到了彭加勒和马赫很大的影响。

[ ] 右撇子是因为不能同时思考两件事造成的,除非反复训练变成肌肉记忆,比如敲键盘打字,弹钢琴等。而世间万物总是有新情况需要应对。

[ ] 对三体思想透明的上下文思考。

[ ] 思路和意图对,是因为我们是上下文,但是没有涵盖到所有上下文,所以代码还得调试测试。

[ ] 自然语言可以多大改造,好像不行。

[ ] 测试就是两个主体之间相互确认沟通。

[ ] 打印图灵,邱奇,的论文。

[ ] 在编写一定量关于该需求的代码后,才发现其内在结构。

[ ] 人不根据逻辑来理解事实,而是根据直观经验里理解事实。

[ ] 未来编程语言的发展就是尽可能探索人类思维和逻辑之间相辅相成的表达和理解。对于前者在编程语言里作用的思考到目前为止都太少了,而且我们关于人类思维本身的运作也所知甚少。

[ ] 从来没有人想到自然语言有其不合理性。

[ ] 音乐就是一块一块的。不过除了思维,人类构建的都是块。

[ ] 除了感官间信息量的上下文对比,还有更多未知的,比如瓦格纳音乐对灵魂的颤动。

动物等级,生育理论。男女平等,二次曲线,最终平等。女人适合写代码吗,1,体力活,2,智力活。1,为什么女人思维多进程。

[ ] human 编程语言是对结合人类思维和逻辑的一次尝试。

[ ] 自然语言的缺陷,假钱买鞋的难以理解,昨天今天明天。 [ ] 紧密沟通,促使语言简化,比如油画到抽象画,汽车标志由繁致简。

[ ] 自然语言的含糊性是思维降格为文字导致,因而是本质的。

[ ] 人类知识和真理的延伸是经验之外的,因而不建立在经验之上的沟通,因而必须是由个人来突破,真理的首先是个人的,从而成为全人类共有。

[ ] 原子事实就是上下文里的直观经验。

[ ] 谈话缺省的部分,恰恰是逻辑隐含的。

[ ] 理解是不可理解的,因为理解是递归的。

[ ] 文法词法规则并没有真正理解语言,统计翻译只是在其上层而已。

[ ] 哲学的功用在于用思维来思维思维,不是治疗或讲道理或什么别的。应对王宇光说的 http://www.douban.com/note/54252462/ the big bang theory

[ ] 目前我思考的哲学只是为创造 Human 编程语言做哲学理论基础而已。

[ ] 主客体分离是 生命赖以存在的基础,使得一切成为可能。比如地球不为某人意志而停止转动。

[ ] 对commit的尊重,其实就是类比于对自己过去退学等选择事实的尊重。

[ ] 美永远是一种不可捉摸的东西,永远值得人们探索。只要心灵没有麻痹,那么相对于丑和无聊,美就是新东西,永远新的东西。

[ ] 人类思维永远是在二次以上确认的,所以luiti的数据测试很应该。比如忽然觉察到一个蹊跷,就证明人脑在多次确认。可是原理却是我们还不知的,可能就是连绵不断的注意力。

[ ] 思维本身就是反复的,即苦苦上下而求索。

[ ] 上下文证明了哥德尔不完全定理,因为即使自然数定理也是有悖论的。

[ ] 用上下文的what来解释世界的why,只需要这一个模糊的假定。

[ ] 只能利用它,而不能造出它。也许逻辑是传递上下文的信道。

[ ] 不是因为everything有个core,而是思维理解事物就会弄出个上下文来,是为core。

[ ] 女朋友喊洗衣机坏了,其实是灯开了但是不能转动,因为水管坏了。俊晨喊YARN挂了,其实是他用配host的本机看网页版的 YARN 不能访问导致。而TA都是学历高的人。

[ ] 黄种人的面平,没有西方的立体面孔,导致表达晦涩。可是孰是原因呢。

[ ] 写一本小说《和机器人打交道的人》,人的性格等是机械的,另见《人是机器》。

[ ] 关系不是本质,本质是为什么有这个关系。

[ ] 用语言思维并不意味着思维是语言。而是像英文单词由好几个音节组合而成,思考时却是作为整体。所以即是思维习惯于归一,简化。

[ ] 我不太关心不理解,我更关心如何不理解。

[ ] 物质可以无限分解,“关系”一词可以分解吗,数字“42”可以分解吗。

[ ] 数据和逻辑的关系是什么,再是数据是什么,数据就是上下文,被人类在思维层次理解的,虽然本身有很多统计特征,可以被编码为布尔逻辑,再是丘奇数。

[ ] 我们只能利用物质运行相互关系来构造逻辑机器,而不能像大自然一样自发组织。

[ ] 发现相似性和组合性是人类思维的本质,这样可以聚焦于一个上下文。

现实问题

  • 因为 Human程序语言 是依据人类思维 而设计的,所以它可以辅助人类编程,尽可能降低程序复 杂度。

Thoughts

  • 写程序不单单是和机器沟通,更是和未来要看这段程序的人沟通的。试想要给另一个人讲解代码 ,首先你自己会在代码的每个层次上广度优先讲解,其次针对对方的提问,这提问却总是在一 个层次上的(如果对方提了两个层次,你也会给对方分成两个层次讲),所以这一个层次的相关 代码以某种方式集中在一个地方是有好处的,就像我们真实世界所谓有条理的布局一样。 -- - 和函数式编程的固定输入输出一样(即变量不可以被重复赋值),把语境严格的划分在人类思 维完全可以理解的范围内也是可行的。

  • 人类思维是否都是完全等价的。即只要有足够的耐心和时间讲解,对方一定会明白,然后 TA 也 可以这样讲解给第三者。类似计算机的 CPU 和 IO ,以及信息传递。

  • 在代码文件布局上保持在每个层次上都有一个 self 。Java 里的目录命名空间也是一种方式。

  • 逻辑以直观为基础。而直观是可以被灌输的,不管是经验,或教训,或推理。

  • 真的是代码吗,体现的都是人类的思想。

  • 源代码组织也是重要的,比如不能太杂乱。认为编译后代码一致,或者从最终输出出发是不够的。

  • 取决于你目标的上限,hard 模式是综合速度最快的,远快于easy 模式。

  • 为什么仔细想好写代码比快速实现在综合情况下更好。因为人类理解概念是按层次和组建来划分 的,仔细想好写代码就意味着这些原则,而快速实现是暴力地把一大堆想法直接压扁到纸上,唯 一的原则就是快速而正确。所以快速实现只适合短跑项目,即一次性小任务。

  • 美(艺术)是什么? 除了一些基本原则(比如黄金分割,复调呼应)外,好像无法从人类的思维特质里得到。

  • 运行错误栈取决于你认为的底层位于哪条界限。一般编程语言位于自身,其上是库。

  • 语言不是公式推理,它的功能不是说像lisp一样拥有最小语言特性就好了。而是为人类思维和逻辑 之间提供方面的桥接以及生态系统。

软件工程

  • 程序员写代码时考虑的是以后别人如何来看这段代码,而不仅仅是符合业务逻辑的代码即可。 这点和画家很像,考虑的是别人如何看。音乐和文字等时间性的东西就没怎么讲究,更多是考虑 自己当时的审美。

  • 最底层核心业务数据按照UI设计是可怕的。这说明的是直接纵向设计到底是不对的。

  • 好代码的标准:1。三秒内明白这几行代码对于全局的作用。2,半分钟明白全局架构。两者都不 用太知道其中原理。

  • 在多层循环时,习惯给每层变量后面加数字,用于表明是归属于第几层的。个人代码习惯而已。

Questions vs Answers

Q: 文学编程的优劣?

A: TODO

Q: 选择 CoffeeScript 作为试验 Human程序语言 的原因?

A: 1. 用空格缩进来表达程序语义,并且比同样采用空格的 Python 更简约和有表达力(比如多行 lambda)。2. 作者 @jashkenas 支持文学编程。3. 非语法上强制,最终都可以编译到诸如 JavaScript等语言。

目前作者我对于实现编程语言还有足够理论和经验基础,不改变编程语言行为,而只约束编程规 范,这样对于作者我或者用户来说,成本是相对最小的。而且基于 #Human程序语言的理念# , 程序语言的范式和语法和库等,都只是作为思维对象而存在的。

Q: Human程序语言 的理念。

A: Human程序语言最大的特点和优势就是在于革新了人们关于编程语言的观点。不再以穿插在各个 层次的并导致混乱不可维护的代码为思考点,而是以人类的思维作为出发点, 人类只善于在一 个上下文里自由地思维最多六七个对象。对于把程序实现作为目标的程序员来说,需要同时兼 顾好程序各个层次,以及业务各个层次,调整和理清每个部分是至关重要的。

Q: 思维的本质。

A: 在我看来,思维和自我应该是等价的,首先想到的原因是自我必须或只能通过思维来确定自我 存在。详细论证得从哲学和脑科学等多方面来研究。 TODO

Q: Human程序语言 到底是编程语言 还是软件工程法则?

A: 首先是一个软件工程法则,但是会让编程语言更有利于表达这一法则。所以可以现在其他编程 语言上尽可能实现,在有足够经验或不好实现时,会逐渐构建起来自己的编程语言。

Q: 什么是最佳代码(和具体何种编程语言无关)?

A: 最佳代码就是意味着尽可能好的工程实现。对于对方提出的任何切实问题,都可以在视觉上很 容易(几秒到几十秒不等,等价于一般人类等待网页打开的时间)。也即是代码尽可能在各个层 次解释。

Q: 软件工作者 可以留下什么?

A: 生产的软件不仅自足,还可以作其他续用。比如公司一个内部项目,分离出一个MVC框架,开 源了,别人可以继续用和改进。

Plan

  • 用 CoffeeScript 来实现第一版 语法和语义验证器。 具体原因见 #选择 CoffeeScript 作为试验 Human程序语言 的原因?# [20141026]

CoffeeScript

  • 好处是更让人觉得语法是为表达服务的,而且很容易理解不同形式的转换。

Human编程语言 设计草稿

  • 一个 if 里最多不得超过六七个条件
  • if else 因为它的扁平型,是可以无限个的,但是一般用户也不会和没有条件这么做。
  • 面向对象的根基是类。类可以把数据和行为捆绑起来,这样以数据为节点, 行为将它们连接起 来,因此这样的本质性就是数据。函数式编程,或某些动态语言(比如 Python 把函数作为第 一等公民) 把过程和数据同等强调,甚至可以修改自身,因而获得极大的灵活性。我意味函数 就相当于故事。人类是用故事来理解世界的,评判一个人的好坏功过莫过于此。而故事是扁平 化而易于理解的。
  • 增加一段足够长度的注释就得一分。
  • 概念越多,得分越高。但是同时也得排除概念的重复度或重复部分,这可能可以通过语义分析 来得到,比如编译后的 JavaScript 。
  • 既然是层次化,能否静动态混合类型编程呢,用于提速或安全等目的。一部分是机器码,一部 分是类似JVM,一部分动态。
  • 既然在每一个层次都是逻辑,那是否可以完全的加速呢,或者程序自己显示消耗出现在什么地 方。
  • http://www.alorelang.org/doc/typeoverview.html Alore is a programming language that supports both dynamic and static typing,and a mixture of both in the same program.
  • 1.2.3.4.5 序列化编程应该融入编程语法。

Copied From Reminders And Stickes.

[ ] 类型检查应该是可以自定义的,因为它确实有很多好处。

[ ] 考虑每个文件的函数导入,重点不是限制七个并再分类,而是更多属性或形容词描绘。

[ ] 函数式语言的变量不可修改,意味着最小单元,所有都是最小单元。

[ ] JavaScript只是交不交IO控制权的问题,比如像JavaScript强制要求在语言层面分离。而这在Human里可以通过子执行单元和定义组合式来分离。所以对Human来说,解决问题是子执行单元,之前我设想是类似erlang,但是得有监控。

[ ] 打比方而已,语言相当于计算机的IO,而思维是CPU。语言是用来持久化和人们沟通的基石。

[ ] 补充一下,人对于现场的某一事物其实是反复和多角度思考的,即是不断变化,或者暂时认为一个可行的观点。这体现到程序里,即是人是明确知道自己想要什么的,功能实现和测试是方案的两个角度。

[ ] Haskell自己也承认并行难以调试,那也许Human不应该由Haskell来实现,还有我现在也对这门语言没有经验。

[ ] 语言即是开发者思维本身。

[ ] 人类压根就不擅长逻辑,世界是逻辑的,就像身体上的疾病是某一原因一样,可是现代医学至今还只是皮毛,没有彻底解决过医学问题。

[ ] 并行和并发用现实世界的人类协作方式理解就好了。定义各种postman,guest等,让人之间根据角色去调度,把计算机复杂度降级为日常人协作的复杂度,人和人之间通过事件来触发,拒绝计算机的抽象概念。

[ ] 意义哲学。上下文哲学。

[ ] 永远没有人工智能,除非对方有人工智能;然后陷入递归定义。所以永远都没有人工智能。

[ ] 为何不可能有人工智能,因为自然界只有人类有智能,而其无法被自然界的相对论或量子理论或图灵完全所完全诠释。

[ ] 人类被自身所奴役,人类是自身的上帝。

[ ] 还原论的悖论。如果真的还原到一个终极真理,那么还原过程如何用这个终极理论解释。

[ ] 正像弗洛伊德利用自创的精神分析法分析自身一样。

[ ] 创新本身就是挑战公共上下文的过程。

[ ] 用人类思维来入门编程语言,比如列表就是一组元素,字典就是说一个事物名称马上想到相关图像。虽然编程语言本身是逻辑的,但其实也是日常的。

[ ] 还原论的弊端是导致了一批聪明且自以为是且自大的人,比如应试教育。

[ ] 本质上没有鸡和蛋孰先孰后的问题,鸡的诞生就和其他动物一样,只不过借用了蛋的方式。

[ ] 如果创建好了人脑思维语言,那么其他都不必放入语言核心了。

[ ] 函数本质就是数据的变化,思维通过数据来思维变化。

[ ] 修改其他局部的代码必须先问候,这是一个礼貌。内部变量是可以暴露,但是外部访问这个变量必须显式一些。所以基本上,内部变量不被访问。

[ ] 对于函数来说,为了避免多线程覆写和竞争问题,函数应该是无副作用的,就像去除类变量这种奇怪的东西一样。如果函数带状态,那它就不是一个函数,而是一个人,即是通过事件来访问,单进程的JS。或者在语言层面就应该把函数扁平化,使之无副作用。

[ ] 一切问题的解决都得从本质入手,深入上下文。

[ ] 三体人的思维透明和编程语言联系在一起会很有意思。

[ ] 数据的变化就是关系,人类只能理解关系,而永远认识不了本质。所以从数据结构来认识程序最直观简单。用数据来理解和衡量变化。

[ ] 需求来自于现实生活,那必定可以重现为现实场景。

[ ] 没有所谓蝴蝶效应,它应该是整体的,真正背后的驱动。

[ ] 非还原论者,而是上下文者。因为世界不是一层一层构建起来的,而是任意维的上下文。

[ ] 函数匹配和单词一样,第一个和最后一个必须一样。中间部分随意。

[ ] 比如空格多余,应该强调在当前文件里风格一致,就是你可以 2*3 没有空格,但是当前文件的其他地方也必须这样没有空格,这样就强迫其他人使用更好的规范啦。还有包括类命名,一致为驼峰式,或者下划线式等都可以,只要当前文件内部一致即可。然后如果引入其他类,如果风格不一致,那么就必须做别名。归纳一下,允许不同风格,就像这个世界上有许多语言一样,但是必须内洽一致。

[ ] 数据(持久化结构)和函数严格分离(行为),并且点操作上,数据有更高优先级。

[ ] 一种感觉可以被反复琢磨,因为总是不可分解,难以名状。或者哲学家概念中的新的却是日常的熟悉词。

[ ] 时间和空间也是被人脑理解,言语也是被理解的,两者都被人类用于交流,所以时间空间其实是人类自身里的啊。

[ ] 软件系统是复杂的生态,人们会抽取一个系统架构,比如nginx, MySQL ,但是这是不是也是一种比喻呢,或者在思维内部是否和比喻同源呢。

[ ] 过多使用视觉,而少使用听觉,算法依赖听觉,强调时间性。

[ ] 1. 明白大概的算法复杂度后,就可以有问题时引领自己去搜索解决了。2. hangman 用统计的方式,这个事先不知道。

[ ] 重点不在于构建直接穿接到最底层的逻辑操作,而是强调每一层,或者各种上下文里的逻辑自洽。这也是前端水很深,不需要底层知识的原因。敬畏现象是很重要的,要么敬畏,要么分析。

[ ] 组合式函数,让人更注重于意义。至于是否合法,则用机器逻辑来辅助检验。

[ ] 其实只需要少量上下文即可。从文本看,也就几句话或一段话。而某名词的含意则是另外的事。

[ ] 意义。人们明白语言,可是无法解释词组组合的意义,稍稍更改就意义大不同。

[ ] 并没有蝴蝶效应,而是后面更本质的原因导致了一切,蝴蝶煽动翅膀只是本质原因在路上无意碰到的而已。所以这是一个以结果论因的谬误。

[ ] 人类思维是图像而有富有律动的。

[ ] 一个简单的证明,人脑不是逻辑的。比如软件开发需要测试,测试相当于业务的另一个实现。而程序员大量时间都花在DEBUG和测试上。

[ ] 身体算两个,所以身体部分数量是7。human logo 。

[ ] 和谐是上下文的和谐,人类理解的核心。

[ ] 有限的感官只是为了更好的区分。

[ ] 量词在时空下得以存在。读柏格森《时间与自由意志》第一章有感。

[ ] 人类不是进化而来。而是为了体现智慧,必须由其自我生长。在我看来,注定只有人类才是智慧的。

[ ] 什么是直觉,就是事后检验。比如写完一个程序,运行后的输出,看看是否正确。直觉是内隐的逻辑。TODO,还得再思考。

[ ] 大脑不能归结为物理学里的各种力,这些力只是表现形式而已。

[ ] 康威生命游戏只是一些固定规则,那么必然会收敛到一些状态,这个其实只是数学模型而已。有个致命缺点是,随机性却是由外部系统提供的。

[ ] 程序脱胎于社会,在本质上都是逻辑的,社会是有道德契约的。

[ ] ACM和软件工程区别,一个是短篇,一个是长篇。前者需求固定,不容易更改。后者需求和设计易于变化。

[ ] 解题时一是想清楚大概思路,二是想清楚所有边界细节。后者对人类是很难的。

参考

Copyright

@mvj3 (David Chen)

About

The Design Draft Of Human Programming Language.

Resources

Stars

Watchers

Forks

Packages

No packages published