Open tiye opened 11 years ago
好的文章要有好的图片, 来获得更好的兼容性, 因为文字从来不如图片清晰 把人们比作虚拟机, 文字比作编程语言, 词汇量比作类库以及平台的 API 层的话, 没有图片的文章, 不熟悉 Chrome 调试和没看过前个 Issue #59 的同学会没头绪 我总期待能更好地表达, 不惜手写抽象的代码, 却没有及时掌握操控图形的能力 结果无法自己做动画.. 以及这里需要的图片
微软的 Metro 和 Future Vision 中展示着界面将会更突出重点, 更加明了 世界纷繁复杂, 而人们爱简单, 特别是考虑用户界面. 编程同样应该是
文本足够简单通用, 但代码就是数学符号, 各种复杂的抽象 抽象所以强大. 可人们更擅长基于图形来思考 图形界面的调试, 长宽的分配和颜色的对比, 单凭数字很难有好的结果 同样还有代码调试的报错行号, 多麻烦的一件事情
渐渐有 Light Table 这样, 代码编辑的同时展示出运行后的效果 我接触最早来自 Bret Vector 的视频, 拖拽代码中的数字来展示运行效果 最近还有 Sublime Text 和 Chrome 的调试功能 Sublime Web Inspector, Debug Javascript right in the Sublime Text Google I/O 2013 - Chrome DevTools Revolutions 2013
现在我在 Chrome 里调试, 先是断点看数据, 然后改代码运行 某种程度上, 修改的代码被立即 Patch 到正在运行环境中生效 搭配 Workspace 的 CSS 修改也是, 在 Element panel 修改直接映射到文件 我理解这是进入到代码执行的环境中编写, 而不是在脑海里编写 编程总要预演一遍执行过程, 我想执行本身就是最好的预演 当然, 这依赖工具.
现在报错和修改都基于行号, 意味着要跳转行号找到代码更改 Chrome 的调试工具为此增强了调用栈的链接跳转, 显得很迅速 (我只熟悉 JS, 其他调试工具有更好的请补充 :) 其实如果有更好的方案, 行号明显不是必要的, 不过方案的确没呈现出来 我们不再胡行号, 只是不想打破规则而带来困扰
另一个场景是改需求, 这时可能要找对应 method 看代码逻辑来改 问题是, 会需要在大片代码中找到起作用的 method, 而文本形式铺开的代码冗长 折叠或者搜索强大而不完美, 我更期待能超越文本 假想有方案, 查看代码就像我们用 ls cd 看文件夹一样, 在代码每个域跳转 那么更多的复杂性可以被隐藏, 呈现给人们简单的逻辑
ls cd
Dynamic Drawing 视频里展示了更妙的方案, 编程中变量未必要是符号 用户的操作本身也是一种数据, 和函数一样, 能被记录和调用 数据在图形界面中有更好地展开, 对图形的编辑就是数据本身 大概要花很多时间, 才能看到图形体现出来编写程序的便利性 而如今我们的编码方式, 在后人眼里多半强大而原始...
https://github.com/lifesinger/lifesinger.github.com/issues/154 的博文讲到了编程领域的还原论 我想这也是递归的迷人之处, 人们用简单的规则生成了壮观精彩的图案 函数的可复合, 接口的通用, 模块的重用, 让宏大的工程也显得可及
编程我想最重要还是数据之间怎样沟通以及怎样隔离 面向对象的事件, 首要是形成隔离, 使得模块能独立并行开发 函数式编程用函数的域来分隔数据, 以便能独立进行运算 模块化来得更彻底, 因为函数内部能访问外部作用域, 模块就不能
再是对内容抽象, 用更廉价的方案来掌控更多的动作和过程 作用域链是一种, 方法和属性的继承是一种, 简化了数据的定义 一个逻辑的改变, 不应该在代码上造成多次相同的修改, 而增加维护成本
编程语言的改进, 我想就是为了迎合这两类开发上的方便来提升 模块下载用了 Github 用户名和 repo 名称, 图形开发引入模块化, 改标签不用再编辑一次关闭标签, 申请一次内存不需要再关闭一次
我们最后会在图形里编程, 编程的同时就处在代码运行的时间当中 代码的运行过程会在工具中即时呈现, 方便随时调整整体运行效果 编辑的代码总是一小部分, 运行环境一点点刷新和增长, 直到程序完成 工具会记录下每个操作, 因此回退代码能更好地查询和调整以往的行为 程序员不是面对枯燥的符号, 而是各种设计在开发工具里的数据和过程的展示 看那几个视频的时候, 我觉得这样一个未来已经很近了
我觉得未来或许每个人都会编程,应该会有几乎没有学习成本的语言。
@zzz6519003 方向没错, 不过"没有成本"我不认同, 就拿汉语来说, 那么多人用, 学习的成本还是非常高的. 只不过我们有各种办法可以消化成本, 而不至于成为幸苦几年才能入门的技术.
好的文章要有好的图片, 来获得更好的兼容性, 因为文字从来不如图片清晰 把人们比作虚拟机, 文字比作编程语言, 词汇量比作类库以及平台的 API 层的话, 没有图片的文章, 不熟悉 Chrome 调试和没看过前个 Issue #59 的同学会没头绪 我总期待能更好地表达, 不惜手写抽象的代码, 却没有及时掌握操控图形的能力 结果无法自己做动画.. 以及这里需要的图片
微软的 Metro 和 Future Vision 中展示着界面将会更突出重点, 更加明了 世界纷繁复杂, 而人们爱简单, 特别是考虑用户界面. 编程同样应该是
代码不再是文本
文本足够简单通用, 但代码就是数学符号, 各种复杂的抽象 抽象所以强大. 可人们更擅长基于图形来思考 图形界面的调试, 长宽的分配和颜色的对比, 单凭数字很难有好的结果 同样还有代码调试的报错行号, 多麻烦的一件事情
渐渐有 Light Table 这样, 代码编辑的同时展示出运行后的效果 我接触最早来自 Bret Vector 的视频, 拖拽代码中的数字来展示运行效果 最近还有 Sublime Text 和 Chrome 的调试功能 Sublime Web Inspector, Debug Javascript right in the Sublime Text Google I/O 2013 - Chrome DevTools Revolutions 2013
现在我在 Chrome 里调试, 先是断点看数据, 然后改代码运行 某种程度上, 修改的代码被立即 Patch 到正在运行环境中生效 搭配 Workspace 的 CSS 修改也是, 在 Element panel 修改直接映射到文件 我理解这是进入到代码执行的环境中编写, 而不是在脑海里编写 编程总要预演一遍执行过程, 我想执行本身就是最好的预演 当然, 这依赖工具.
现在报错和修改都基于行号, 意味着要跳转行号找到代码更改 Chrome 的调试工具为此增强了调用栈的链接跳转, 显得很迅速 (我只熟悉 JS, 其他调试工具有更好的请补充 :) 其实如果有更好的方案, 行号明显不是必要的, 不过方案的确没呈现出来 我们不再胡行号, 只是不想打破规则而带来困扰
另一个场景是改需求, 这时可能要找对应 method 看代码逻辑来改 问题是, 会需要在大片代码中找到起作用的 method, 而文本形式铺开的代码冗长 折叠或者搜索强大而不完美, 我更期待能超越文本 假想有方案, 查看代码就像我们用
ls cd
看文件夹一样, 在代码每个域跳转 那么更多的复杂性可以被隐藏, 呈现给人们简单的逻辑Dynamic Drawing 视频里展示了更妙的方案, 编程中变量未必要是符号 用户的操作本身也是一种数据, 和函数一样, 能被记录和调用 数据在图形界面中有更好地展开, 对图形的编辑就是数据本身 大概要花很多时间, 才能看到图形体现出来编写程序的便利性 而如今我们的编码方式, 在后人眼里多半强大而原始...
模块化和捷径
https://github.com/lifesinger/lifesinger.github.com/issues/154 的博文讲到了编程领域的还原论 我想这也是递归的迷人之处, 人们用简单的规则生成了壮观精彩的图案 函数的可复合, 接口的通用, 模块的重用, 让宏大的工程也显得可及
编程我想最重要还是数据之间怎样沟通以及怎样隔离 面向对象的事件, 首要是形成隔离, 使得模块能独立并行开发 函数式编程用函数的域来分隔数据, 以便能独立进行运算 模块化来得更彻底, 因为函数内部能访问外部作用域, 模块就不能
再是对内容抽象, 用更廉价的方案来掌控更多的动作和过程 作用域链是一种, 方法和属性的继承是一种, 简化了数据的定义 一个逻辑的改变, 不应该在代码上造成多次相同的修改, 而增加维护成本
编程语言的改进, 我想就是为了迎合这两类开发上的方便来提升 模块下载用了 Github 用户名和 repo 名称, 图形开发引入模块化, 改标签不用再编辑一次关闭标签, 申请一次内存不需要再关闭一次
小结
我们最后会在图形里编程, 编程的同时就处在代码运行的时间当中 代码的运行过程会在工具中即时呈现, 方便随时调整整体运行效果 编辑的代码总是一小部分, 运行环境一点点刷新和增长, 直到程序完成 工具会记录下每个操作, 因此回退代码能更好地查询和调整以往的行为 程序员不是面对枯燥的符号, 而是各种设计在开发工具里的数据和过程的展示 看那几个视频的时候, 我觉得这样一个未来已经很近了