瞎扯淡 申请删帖

jakitto · 2017年06月04日 · 最后由 jasl 回复于 2017年06月04日 · 6439 次阅读

Ruby-china 版主帮来删下帖,谢谢~

Rails 算大型项目吗,维护吃不吃亏,主要还是看人,java 就没有不能维护的代码了吗

对 wayne712 回复

很正常啊,这时候大项目就要做很多 Testing,其实做不做也无所谓,国外有个帖子分析过 Linux 内核,C 是弱类型的,加上没有模块化等设施(facilities),你要想维护不吃亏,完全就只能靠人为来约束开发习惯了,但是,如果约束不好,尤其一些开发经历并不多的个人而且是小项目甚至项目算不上的开发者,就简直可以认为是在瞎写了。

历史难题:命名...

是谁说的Rubyist (Ruby开发者)都很信仰这个(block),『天下武功没有高低,习武之人有强弱』。

写代码,何必这么较真呢?just enjoy coding

  1. block, lambda, first-class function,anonymous class 都在各自语言平台上大量使用,各种回调都能看到。但本质上都是一类东西。
  2. 你说的是开发者滥用 yield, &block,但这只是开发者本身素质问题,并不是语言问题。
  3. 日常开发要用到 yield 并不多,大部分是在一些封装起来的类库中使用。
  4. 如果你说 b1, b2, b3 或者 yield 意义不明,那么 js 那一段也一样不明所以,甚至连 c1, c2, c3 传进去是不是函数都不确定。这个不关 block 或者 function 的事,这类问题上类型系统。
  5. js 的确为回调做了很多工作,promise, generator, await/async。但是你有想过为啥其他语言没有那么多事情?是的,语言性质决定了,ruby压根就不会用到那么多嵌套block,至少,现实世界很少能看到。
  6. 最后,你口中的 Rubyist 到底是谁?
对 saiga 回复

没错的,我说的就是开发者本身素质问题,但是,Matz 居然在会谈上高度赞扬这个,就是要偷懒,就是怎么写、怎么爽、怎么简单、怎么快、怎么来。

如果说这个用的不多,那么就一个日常的 times,就一个 Array 的 each 就是这样迭代,其实回顾历史,以前 Ruby 的不少库就有不少的 leak 现象,然而 Ruby 不像 ObjC 有 weak 引用,其实 Perl 在 Scalar::Utils 也有 weaken,这种方面在深层 clojure 闭包是很发挥作用的。

看了楼上的回答,我不得不说,我昨天看了 Goliath,启动一个服务器读取配置各种 block 嵌套,感觉就像是在写 DSL,我知道作者写得很爽,但是拜托,你叫我怎么看。

为了读懂整个服务器过程,我足足看了半天。后来拼拼凑凑我终于明白了,但是我觉得这不是在浪费我的时间吗?

我读过 Lighttpd / Nginx 的 sources,代码量比它多了去了,但是都没见过这么绕,这么弯【误】的。

It is twisting!

结合我在别的帖子说了打算把 Autumn 移植到 Ruby 大家庭,那么上面的过程应该就知道怎么回事了。

另外,其实我喜欢 Ruby 这门语言,但是我不喜欢这样的用法。

而且,我不喜欢《优雅的 Ruby》、《Ruby 程序员修炼之道》要把这样的用例作为 official style or the most elegant style(官方的风格或者是最优雅的风格),我会感觉:

噢,原来你们都酱紫的。

还有,在跟 @dsh0416 的讨论中,我发现他很倾向于元编程,这样我会觉得 uncomfortable,我会认为:

噢,原来 Ruby 是用来专门制造 DSL 的,别人看不懂,只有自己看得懂,但是很精很妙。但是,别的语言也能写很好的 DSL 呀,JSP 这门 DSL 这么多年历史了,ASP.net 也没站在来,what about JSON?我不是不认可你们的精妙,我只是觉得,这样太不可维护了,估计就是自己拿着玩。

对 alex_l_zhang 回复

开玩笑,其实我还是很喜欢 Ruby 的,说的是不喜欢某种风格。

Ruby 解决问题的方法不止一个,方法论也不止一个。我看到不认同的方法论也就知道一下,不会一杆子打死 Ruby 或者 Rubyist。

围观。。

对 jakitto 回复

先纠正一下,Ruby 是有 WeakRef 的,多看看文档源码。并且 ObjC 中的 weak 大部分时候解决的是循环引用,这个问题在 GC 中不存在。

另外 yield 本身存在更多的意义是编译器性能优化,类似 Swift 语言中,escaping block 和 unescaping block 的区别。如果不明确使用 &block 语法将 Block 转换为 Proc 对象的话,这时候 Block 不是一个对象,在大量存在 Block 的语言中这是一种性能优化。

JS 中的 Promise 存在的原因是 JS 大量异步操作是依靠回调的,而且 Ruby 中大量 Block 的存在是为了写出更通用的函数,两个语言中的高阶函数想解决的问题并不一样。

Ruby 和 Rails 在设计上要达到上层开发者爽,那么下层必然要付出更多的努力去实现元编程,这就是一种权衡。无论是 Lisp 还是 Ruby,包括 ObjC 的 Runtime,一切有元编程能力的语言都会带来底层代码维护难度增大的问题。应用构建可以选择自顶向下,像 Java,也可以选择自底向上,像所有支持元编程的语言那样,为你创造出一种新的写代码的可能性。

Java 是个好语言,企业级一定是需要一个强类型系统的编译型语言的,但 Ruby 也不会死,弱类型语言后期一定是需要大量测试用例来保证鲁棒性的,这就是综合选择的问题了。

最后,没人阻止你给方法起个好名字啊,Ruby 给你提供了可以更加接近自然语言的语法,但是你非得给人家起个 m1、a1 这样的函数名…放在什么语言上你也看不懂它的调用流程啊(摊手)

对 Rei 回复

其实我不是不认可,我是接纳这种实现,只是觉得它有它的优势,只是口味而已,因此我觉得你说的:

我看到不认同的方法论也就知道一下,不会一杆子打死 Ruby 或者 Rubyist。

也是认可的,所以在上面回复说:

天下武功没有高低,习武之人有强弱

来区分用法,我觉得,呃,我面试过新人,然后我能理解初级开发者都比较喜欢简单去实现,因为他们也暂时没有能力用与之更好的办法实现,我觉得只要不是说谁一定吐槽谁,尤其我也不喜欢新人搞一批主动设计,因为新人参与设计往往会搞乱设计,但是说他们能快速完成任务,这一点倒是认可的。

没有绝对否定,只有站在某个角度来观察的时候,能看出某些问题,我也只是把问题表达出来,大家奇文共赏。

1 block 是 ruby 的一部分,你若需要使用 Ruby,那你就要了解 block,

你说 JS 还能做类型检查,首先我们不讨论 JS 糟糕的类型系统,Ruby 对于 block,需要做“类型检查”么?不需要,用 block_given?

def obj.method(name, &block)
  str = "Hello #{name}" // 拼接 Hello 和变量 name
  yield if block_given?
end

这才是 ruby 风格的代码,Ruby 的语法设计,注重的是提高表达能力,你指出的场景很常见,所以 block 可以很好的屏蔽掉类似 js 那种传入函数作为回调时干扰视线的 function()

此外,这里反倒体现了 Ruby 的简洁,有一种场景 临时打开一个文件,做一些操作,关闭文件

正常的写法:

file.open()
// do sth
file.close()

如果你写过 Python、C#,你知道他们提供了 with 语法,这是语言提供的机制,而 Ruby

file.open(filename) do |f|
  # do sth
end

这是 open 方法自己就可以做到的一点,不需要语言提供支持。

2 这跟 Ruby 没关系,你用任何语言都可以写出这样的代码,yield 也不是 Ruby 的专利,既是不是 Ruby 的 yield,协程也可以产生类似的问题,不要把逻辑的设计怪罪到语言头上。

顺带装个逼,

根据 Kleene 正规型定理,任意偏递归函数都可以由原始递归函数经过一次极小化得来,所以写程序的时候如果发现两层以上的无限循环要格外小心,很可能逻辑是错的。

当你写出如此丑陋的代码的时候(任何语言下都可能发生),那很可能你的逻辑出了问题。

另外,Promise 是一种风格,你希望在 Ruby 中使用 concurrent-ruby 拿走

3 Ruby 也可以的啊,Keyword arguments,如果你认为这个风格好,可以用啊

4

还有的就是,Ruby 居然延续了 Perl Pod 文档的风格,各位可以自行用 perldoc 或者 man 看一下,总之这些文档只告诉别人传入些什么,不告诉别人返回类型,我当初写了几年 Perl,我发现 Perl 这样做很让我火大,dbm 有时候到底返回了哈希引用还是就是哈希,有些时候我要自己去试。

JS 不是这样?Python 不是这样?

这个确实是问题,有很多人吐槽过,Python 有 PEP484 虽然群众更希望 Python 2.7 一万年,Ruby 也在做类似的改进 —— Soft type https://ruby-china.org/topics/25428

JS 你恐怕需要 Flow(Vue 在用)、TypeScript 了,短时间看不到 ES 改进的希望,另外,ES 的类型系统... wat?

5

因此我可以推断,以 Ruby 为友,或许你会活得很累。

Matz 发明 Ruby 是在 93 年,目标是快乐编程,正式发布于 95 年,最终在 06 年 Rails 发布,彻底引爆了一波节奏,

Rails 的信条 之 程序员的幸福最大化

是 Ruby 造就了 Rails,所以第一条信条便是从创造 Ruby 的核心理念所提炼出來。

早期 Ruby 的极端邪说就是把程序员的幸福度放到第一位。还把追求幸福置于驱动编程语言与生态圈前进的考量之上。

06 至今,到底累死多少人了呢?

对 qinix 回复

呃,我突然想起来,那我也得纠正一下,Ruby 是有 WeakRef 类,MRI 并不是 ARC,因此解决循环引用应该没问题,但是早期版本明显有 bug,我也只是提出来作为参考。

你说的 yield 编译器优化的问题,在 under microscope 有说过,能理解。

另外我说的 JS 的 block 跟 Ruby 的 block 还有 Promise 引出来不代表意思是说他们意义、目的是一样的,其实 JS 也有 Arr.forEach(function(item) {}) 用例,其实他们完全不是一个概念,应该分开讨论,我只是引出来作为参考,还有的就是,我真正想说的东西其实文章漏了:

Ruby 的 do end 写起来很像 DSL

为什么这么说呢,因为没有统一跟函数定义一样的语法,你看 JS 都统称 function,只是 block 是匿名函数的别称(其实也有命名函数作为参数的用例)。

还有,我说的不是起名字,是上面的意思,为什么 block 要另外设计一个语法?

他们不但没有做类型检查,反倒是去改变语法

Javascript 是因为语言本身设计缺陷,所以才需要检查传入的是否是 function,Ruby 已经声明这是一个 blcok,你不可能给这个方法传入第二个参数,完全没必要进行参数类型检查,常见的只是用 block_gvien?检查一下是否有 block:

class Foo
  def bar(name, &block)
    str = "Hello #{name}"
    yield str if block_given?
  end
end

foo = Foo.new

# block是可选的:
foo.bar('world') do |str|
  puts str
end

foo.bar('ruby')

如果你没有认真学过 Ruby 这门语言,或者只是扫一眼浏览式学习,你根本不知道 yield 做了什么。

对于没有认真学习又 blahblah 的人,最好的回复是:RTFM

我去掉了 &b1, &b2, &b3,看看可读性如何,在你看 obj.m1 的时候,你知道 yield 传入了什么吗?看 obj.m2 的时候,或者本来就是从 obj.m2 看起,这时候你肯定会不知道 yield 传入了什么,总的来说:

yield 本质就是占个位,写 yield 目的就是为了无需知道传入的 block 是做什么,如果要理解 m2 的 yield 传入什么才能读懂整个代码,那说明这里不应该用 block/yield 去实现这种需求,写成这样是你的代码设计有问题。

但是,ES6 新增了 Promise 和 Generator 已经解决了这些问题,把所有的异步都给我串起来!!!让你们看看什么才叫真正的优雅:

如果你认真学习过 Ruby,用 block 做 callback 使用也可以写出很优雅的代码,否则就算用 promise 或者 coroutine 也能写出不容易理解的代码,而且你举的代码例子无论从命名和实际用途都不清,如何评价是否优雅?show me the REAL code

(最后,个人认为 coroutine 最优雅)

真没见人说过这样的代码优雅,楼主不要写一堆烂代码然后来喷“优雅”

而且这种语言风格之争一点意义都没有,不喜欢用你就用别的呗

写个代码扯什么信仰,我从来没见过论坛里别人经常用这个词,我看你就是来搞事情的

楼主写了很长一段东西也没有什么逻辑,看完没有任何收获

还有上次跟社区朋友 @dsh0416 的分歧,我看他比较喜欢 meta-programming(元编程),呃,我觉得没问题,只是,你要做好 meta constructor,而且,我觉得 meta constructor 是很不好维护的,这种东西可以节省你写的时间,但是你后期维护,如果你站在这个平台上去开发稍微有点规模的应用,我看不好办,就像 vue.js,你怎么都不能跟 React / Angular2 比,为何,我觉得他说的轻量,应该是代码量的轻量,你这个是 meta generator engine(元信息引擎),如果我要给你开发扩展,或者利用现有的模块再次拓展,很难,为何,因为你这样写相当于做了个微内核,啥都包含在几乎只有一个函数里面,扩展一般以 extend、mixin,你这只有一个独立的东西,叫我怎么扩展?所以这种东西再流行,也太 single 了点,如果你自己精力不够,打算放弃了,那么整个东西就彻底性瓦解了,因为几乎只有你一个人维护。

你这句话很容易证伪啊。。。(似乎已经证伪了)

对 jasl 回复

没错,你引出来的文章棒极了!就是这个 feel,表面上所谓的幸福,背后多少人的努力,如果你要设计一个很漂亮的 DSL,是的很简洁,但是你必须得承担一个很厚很重的而且甚至是臃肿在你这唯一的单个处理里面,vue 就是这样。

上面还有一个回复已经说了,这是自顶向下和自底向上的问题,其实我觉得确实没有可比性,你要 DSL,可以,方便快捷,但是你得自主承担后期异常行为的风险,如果 DSL 底层一改,是不是你上层都要重写?

我风格是自底向上,我认为是比较稳定和具有强烈的行为正确却任性,但是代价就是付出大量的代码和物理手段的抽象。

我觉得只是一种讨论,没有说谁对谁错,只是摊出来大家自由分说。

对 jakitto 回复

你要 DSL,可以,方便快捷,但是你得自主承担后期异常行为的风险,如果 DSL 底层一改,是不是你上层都要重写?

API 改写,难道上层就不用改么?怎样的设计保证了,底层改变,上层就不用改的?

换句话问,如果能做到这点,语义化版本是做什么的?

对 jasl 回复

我没有认为很差呀,我只是说,这样比较窄,不代表作者所做没有意义啊,Ruby 就是这样,作为 multi-paradigm 定位的语言,既然设计成这样,就应该承担这些。

如何证伪?有何真伪?你难不成说这个对那个错?然后自己拿出自己所认为正确的就说这样就是正确的?也太自以为是了。

对 quakewang 回复

JavaScript 是存在语言设计缺陷,它还有存在的缺陷呢!!!为什么现在浏览器都还不支持 import(排除 Safari 或者别的浏览器最新的 dev beta 支持),那么它优势在哪里?

然而,但是它的缺陷正好可以原型编程呀,作为 prototype-programming 的语言,凭借任何理由说唯有你的 class-base-programming 才绝对正确?

另外,RTFM 没有绝对的标准性,只是告诉别人经典用例,但是所有语言每年都有在更新,明年的 Doc 又是另一回事了,就自我矛盾了?(这样会让人感觉你很善变)

对 jakitto 回复

原型链继承跟 class-base-programming 有冲突么... es 6 的 class 还有 TypeScript 的 class 是什么...

Ruby 的继承还是靠祖先链完成的呢... 你到底是真懂假懂...

对 jasl 回复

对的,所以 Swift 3.0 导致了一大波的重构,最基础的 for 居然禁止了 C-style 的 for!!!然而变化多端的 Apple 会随便还让你继续用 2.x 吗?

对 jakitto 回复

你也没解答 "API 改写,难道上层就不用改么?怎样的设计保证了,底层改变,上层就不用改的?" 啊

对 jasl 回复

class-base 和 prototype-base 这完全不是一个思路的东西,另外,请不要把 TypeScript 称为 ECMAScript,思维定位都不一样。只要是 DSL,我们都可以认为是另一个次元的东西了。

ES 6 的 class 你创建过没有,你确定它跟 keyword function 创建出来的不是同一样东西?

对 jasl 回复

对于:

"API 改写,难道上层就不用改么?怎样的设计保证了,底层改变,上层就不用改的?"

回答这个问题:你应该听说过 Mach,听说过 POSIX。

对 jakitto 回复

亏你还在我那个 FormCore 的帖子下回复... Ruby 的 class Foo 关键字,几乎等同于 Foo = Class.new

对 jakitto 回复

你这也是答非所问,API 没改过,上层程序当然不用改。

就算你答了我问的“怎样的设计保证了,底层改变,上层就不用改的?”,可“API 改写,难道上层就不用改么? ”呢?

对 jasl 回复

大叔别生气,我来告诉你 JS proto 的口味吧。。。proto 编程,是指,你 clone 了原型对象(对象拷贝),然后再利用这个对象来编程,而 class 编程,是指按照 class 的模型来 new 对象。class 有层级关系,Ruby 按照你要 new 的对象作为模型进行 new

这篇文章的错误已经发展到了就算放到上世纪末也会被喷。顺便一说,之前反编译完那个楼主巨牛逼的 Autumn 框架后,我就发现这个所谓的使用了「非阻塞」设计的框架完全就是阻塞的,性能非常差,稍微跑个 benchmark 就能发现。之前只是知道结果,读完这篇文章我不难找到了原因,因为楼主对所有涉及到闭包概念的理解全部都是错误的。把 yield 认为是 goto 的,从算法导论到数据结构到编译原理都需要重新学习一遍。如果不是被点名了我都不想回复这篇文章。

对 jakitto 回复

那不还是因为 JS 没有真正意义上的类型系统么... 缺陷居然被你说成优点了...

"Ruby 按照你要 new 的对象作为模型进行 new" 和“你 clone 了原型对象(对象拷贝),然后再利用这个对象来编程”有什么区别?

对 jasl 回复

DSL 引擎有“这一层平台确定性”,如果你使用了,就必须得遵守但是万一某一天改出 bug,如果维护者本来就抱着兴趣而非商业,用户不自行处理还能怎么办,那就得改。JSP 有商业级公司在维护,但是 Ruby 要是编程风格就倾向这样的话,过于热衷自顶向下,就会产生个人引擎,你自己都另外开了一个平台了,但是如果你离职了,谁处理?

对 jasl 回复

你确定隐式转换绝对没有好处?

对 jakitto 回复

你设计的 API,你离职了,谁处理?

对 jakitto 回复

隐式转换有坏处,但是在接受范围内,显式转换,你为什么不去写 Idris?只要程序可以编译通过,是可以连逻辑错误都没有的呢

对 jasl 回复

我觉得以楼主现在 Objective-C 的理解,看 Idris 大概是看天书吧。。。

对 dsh0416 回复

我一直以为写 Objective-C 的人会更容易接受 Ruby 的呢...

对 jasl 回复

如果今天还认为 Objective-C 比 Swift 好的,至少在 Type-safe 的问题上是落后于时代十年的。

对 dsh0416 回复

上世纪什么年代呀,你确定源码没使用 accept_nonblock?你对闭包的概念错在哪里了,你觉得你对在哪里?

对 jakitto 回复

你看,你以为你用了 accept_nonblock 就认为不阻塞了。要真这样,Ruby 下的 Web Adapter 几乎全是不阻塞的。把你代码的 accept_nonblock 改成 accept,性能不会发生任何变化,这个 accept_nonblock 用得完全是错的。

对 dsh0416 回复

还有,我没说你啥都不懂呀,咱们讨论的是实现,又不是人。请不要人身攻击呀,讨论 idris,好歹我写过 LL 文法的解析,我估计,你连 LL 文法都不懂吧

对 jakitto 回复

「讨论 idris,好歹我写过!」 我记下来了。你现在告诉我用 Idris 实现一个 a+b 的函数需要哪几步。

别吵了,反正过不了几个月你们都转 Erlang 了

对 dsh0416 回复

好吧,我看了你的实现,连一个真正服务器自底向上都没写完,不过是用了社区包,我承认我写的很差,根本没做性能优化。但是,至少我没有说它怎么巨牛逼吧,当初我只是跟你分享。这是纯原生手写 C unix 包装 ObjC 外壳的实现,现在也有 Cpp 版本。我当初是向以为你对自己写感兴趣,于是推荐,让你给点建议而已,谁知道你这种性格。

对 jakitto 回复

别说性能优化了,你的服务器根本是不能用的。当 TCP 包不能一次性读回来的时候你的程序会直接奔溃。而且你所谓有业务模型的 Controller 连路由匹配都没有实现,View 层是一个字符串替换。你看了我的实现,你要真看了我的实现还会说我没有 Controller 吗?

对 dsh0416 回复

我没说你彻底没有 Ctrl 实现啊,我说的意思是,你把它精炼到成语法了,想说的是不够丰富而已。还有,你所谓的会 crash,我会说,我可是纯 C 配合 ObjC 手动 parse HTTP,C / ObjC 处理这些的时候肯定具有一定风险性,要是你,我看了你的 websocket.rb,就那么几行代码,你确定你支持 form-data / multi-form-data / ... 几个了?对整个 HTTP 协议支持得如何?

你说你读过我的源码,那么你一定能理解以上原因。

对 jakitto 回复

他那个...你还不知道这个风格的源头是 Sinatra 吧。。。另外 JS 的 express.js 后来的 Koa,几乎所有的语言的“轻量级”Web 框架的风格都继承与此...

对 jakitto 回复

你批评他无耻抄袭都比批评这个 DSL 的风格问题强...

对 jakitto 回复

你的纯原生实现连 TCP 的基础概念的实现都是错的,丢人吧你,还给点建议。你当初第一次找我怎么说的?

我写的,基于 Objective-C 的自制框架,我没用 NIO,而是直接用 TCP + 非阻模型,另外业务比你的强,你这个只有骨架。

TCP 是写错的,非阻模型是阻塞的,Controller 里 return body 直接写死 Hello World,牛逼啊这框架。 接下来又说不想给我看源码,这叫给建议? 还不停追着我喷,我现在是真生气了,然后说我怎么这性格?

对 jasl 回复

我当然知道风格是 Sinatra 啊,我用过但是我不喜欢,你觉得 DSL 在 IDE 会认识会 mapping 吗?所以我后来 C++ 实现的版本,使用的是 std::bind,跟 get "/" method 目标一致。几年前我用 Dancer,不也是这个风格?Dander 就是 Perl 界的 Sinatra。

对 jakitto 回复

还真是会的,你装个最近的 RubyMine 体验下就知道了...

另外,你这个 C++ 实现的版本又要撞队长枪口上了...

对 jakitto 回复

要是真要目标 get "/" method 目标一致,该用的是 C++ 11 的 std::function 的一些用法,用 std::bind 属于用错刀了。

对 jakitto 回复

另外,Rails 的路由都可以可视化的呢... http://tenderlove.github.io/fsmjs/ Journey(Rails 的路由库)的设计相当先进的

队长 Midori 的其实也可以,不过可能要稍微改动点东西

对 dsh0416 回复

或许你没学过 PHP,或许你没用过 CodeIgniter,或许你没学过 ThinkPHP,或许你没看我那篇介绍的文章,写死 Hello World,是为了让你继承这个类,main 作为 Controller 级层需要被覆盖的主方法进行 mapping 的,相当于 Welcome。

另外,你就不过是没看源码而已嘛,叫叫叫的。都被你这性格吓死了。

还有,我测试过阻塞的情况,对比过,我会说,是否阻塞真的影响不大

只是很多服务器都把一个主线程堵死了,然后再去接另一个请求,才导致慢的,其实多线程、多进程足以解决

我觉得对 TCP 理解错的是你,应该说:

你肯定没有用 C 写过 Socket 编程

set non block 就已经设定了非阻塞,你可以非阻塞地读写 socket 而不必卡住系统 IO

是否阻塞,在持久连接接口上有好处。

对 jasl 回复

我觉得,他是让我开源他才能闭嘴。bind 的返回就是 std::function,比如:

std::function<int()> rnd = std::bind(d, e); 

要是真要目标 get "/" method 目标一致,该用的是 C++ 11 的 std::function 的一些用法,用 std::bind 属于用错刀了。

我看他也是来负责娱乐的~

对 jakitto 回复

你不开源但是挡不住被逆向啊... 他不是这个意思,他的意思是“是骡子是马,拉出来溜溜”、“实践是检验真理的唯一标准”

你的发言都是先“造个大新闻”、然后“批判一番”、但是之后就“无可奉告”,你这样很让人“Angry”的,识唔识得?

对 jakitto 回复

还没看源码,你的框架我两天前就反编译把所有代码都读完了。还 ThinkPHP,你的这段代码水平是和 ThinkPHP 一较高下了。

对,你的 Controller 层是要被覆盖,因为连路由匹配都没有 Controller 也不知道是拿来干什么的。拿 PHP 来比较,我听说吹 Laravel 的,ThinkPHP 这种也能拿来吹的,你还是第一个勇士。

对 jasl 回复

噢。。。我知,迟早会开源,衹不过冇系今日。

对 jakitto 回复

那你等开源的时候再说事啊,裤子先脱了,飞机也起飞了...可啥时候降落呢?

对 jasl 回复

也要有准备的~安心等候吧~要不终结话题吧,都议论这些有的没的~他说话也很气人。

对 dsh0416 回复

算了不跟你吵了~哔哔一堆的,你生气了我表示歉意,我可以把文字删掉。你去翻翻你的 40 天自建框架,我看你拿勇气跟社区包比,我也不见得你比人家实现得完整~

你说你读完了我的框架源码,你应该知道里面是带有很多 unsafe 的 C 混合在里面,你明知道可能会 crash,如果没有支持完整的话,这个版本本来就是初始版,所以有何意见?

我说的是参考过 ThinkPHP CodeIgniter 的思维,其实你并不知道,整个 Route 过程是对象反射,而不是 Sinatra 那样的捆绑。

jakitto 关闭了讨论。 06月04日 17:01
jakitto 重新开启了讨论。 06月04日 17:18
jakitto 关闭了讨论。 06月04日 17:19
jakitto 重新开启了讨论。 06月04日 17:23

@dsh0416 @jasl 我准备上真源码,稍等创建 git 项目,稍安勿躁

对 jakitto 回复

你写代码不上版本控制的么...

对 jasl 回复

本地的 git,我说的是转到 Github

对 jakitto 回复

解析 TCP 包 crash 是由你 Objective-C 写的问题导致的,别没事就怪人家 C unsafe,人家提供的 API 好好的。

「其实你并不知道,整个 Route 过程是对象反射,而不是 Sinatra 那样的捆绑。」

路由匹配和你怎么 call 毫无关系,你现在的代码连路由匹配都没有你知道是什么意思吗?

对 dsh0416 回复

我有怪 C unsafe 吗?我说的是,本来就不太安全,很容易解析错误,如果别人发了个错包(不合理的数据),肯定会导致异常啊。

现在框架是初期,又不是 Apache / Nginx 经历了多少年的测试和真实的攻击。

我的路有我自己的规则,“你现在的代码连路由匹配都没有”是什么鬼?

正如楼上的人说,其实自底向上的开发,是要手动处理很多异常问题,开发时间要很长,否则处理不完。

我说的是,我的框架是对象规则反射,而不是手动捆绑。

对 jakitto 回复

我说的「当 TCP 包不能一次性读回来的时候」是正常的包,我甚至都没有在讨论「发了个错包」或者有意的攻击。你的包解析整个都是一片糊涂账,路由匹配啥都没有现在来说「我的路有我自己的规则」,你连 TCP 的规则都不遵守,现在连 HTTP 路由的规则也不遵守,你倒是继续规则啊。你不是还号称

「我读过 Lighttpd / Nginx 的 sources」

你写的这玩意像是读过 sources 的情况吗?

对 jakitto 回复

我说的是,我的框架是对象规则反射,而不是手动捆绑。

实际上....Rails 是直接支持你所说的效果,“约定优于配置”在这里是有体现的... 另外你提的 CI、CakePHP 都是抄自 Rails(或者我们说 Inspired by Rails 吧)

话说,Midori 搞出来也不难吧...

对 dsh0416 回复

你觉得,就算你读完 Apache 的 Souce 你能一天写完吗?

而且,你的 em-midori 代码的 websocket 代码页没有超过几百行,异常的情况也不会有多少处理吧。

你写过,你自己应该知道,我觉得,人与人之间更多的事理解,HTTP 路有规则,你的 midori 完成多少了?这样喷,有意义吗?

我说的路由规则是指根据 URL 来反射对应的 Controller 处理,而不是 Sinatra 那种绑定子方法。

“你倒是继续规则啊。你不是还号称”

我看你是来搞事吧?还能不能好好说话呀?

对 jasl 回复

我觉得怎么实现都无所谓,我们都不过是重复制造齿轮,但是他这种态度,感觉。。。

有一点严重的恶意,就是他不是在告诉你怎么实现更好,而是在找茬,而且你看他说的话特别扎人。

其实我在贴吧碰到过一个类似的人——幻的上帝,然后王垠估计也是这个性吧?

对 jakitto 回复

我百行的 WebSocket 就把 rfc6455 标准中提到的错误情况全处理了,只有一个 Continuous Frame 没有实现,并且在遇到时会抛出,也不会让程序 crash。你以为写个框架这几十页几百页的标准文档是不用看的?你看看 nginx 处理 WebSocket 长连接的部分,除了兼容试验性版本所以加了一堆代码,实际部分也就这么多代码。

我 HTTP/1.1 标准已经几乎全部兼容了,除了标准中非 Web 服务器的部分。你要说「读完 Apache 的 Souce 你能一天写完吗」,答案当然是不能。但也没有就写了一天,就跑到论坛上各种帖子下回复我比你强比你棒的,你这不是拱火是什么?

「我说的路由规则是指根据 URL 来反射对应的 Controller 处理」 你 URL 怎么处理的?你自己好意思说这句话吗。

对 jakitto 回复

Midori 的路由是我协助完成的,功能不弱于 Rails,代码不多是因为我建议与其独立实现,不如直接使用 mustermann

这个库目前就功能上已经成为 Rails 所用的 Journey 的超集,但你读过 journey 的源码就会发现其实他也没花多少行就搞定了,而且我读过市面上几乎所有流行语言的流行的(或者代表性的)Web 框架,路由的设计 Journey 吊打全部,而且 Journey 是一个人独立完成的(Aron Patterson)

对 dsh0416 回复

呵呵哒,你确定我写了一天就跑到论坛上回复说我比你强比你棒之类的?

好吧,算我问的方式有问题,但是实际上我的意思是只是发表看法,好坏不好说。

对于你 URL 怎么处理的,你刚才不是说看了我源码么?上面也说得很清楚。

咱们只做讨论,好好说话。

在你的帖子,我根本也没说什么,后来我都补充说:

我是跑来娱乐的,公司后来不用,就暂时放一边了。

你没必要在意这些,你认真看看我的回复(我刚已经看了一遍了),我说,这就像是一杯咖啡,问一下你觉得这样。仅此而已,你干嘛好像被砸了腿一样的。

自尊心太强,然后非得把别人说的都不是,我怕了~都不敢跟你好好沟通了。

对 jasl 回复

呃,原来如此。。。还是上面说的,我只是自底向上探索,肯定实现成本要高很多。

我写这个东西是为了学习的,所以用底下的东西好了解。

最近被逼著用 CI 邊寫邊想念 Rails😟

对 hong_xin 回复

公司业务,没办法的,习惯就好。其实 CI 可以有办法写得很 Rails,不过要制造很多齿轮。

对 jakitto 回复

你要探索什么呢?看过逆向的代码完全找不到重心,什么都碰了,什么都只摸了一个 hello world,但另一面看过你在知乎上的各种回答,又安利大家用你的 Autumn,一个学习的东西就这样去推广了,确定不是害人?

而且,一个生产可用的 Web 框架,从 TCP receiving -> HTTP parsing -> Routing -> Requst handling -> Responding 每一个点里面都有无数的细节,而我们看到的就是一个很普通的玩具而已。

对 jasl 回复

倒是希望你也可以加入开发呀,我已经把源码传好了。

有什么不足就加入补丁,学习的东西如果不推广,怎么可以让别人也加点好的想法?

所有生产可用的东西,都是这样过来的,PHP 不也是?最初只是为了处理个人网站的网页的 Perl 写的小程序而已。

对 jakitto 回复

其实更核心的问题是,你怎么看待 Web framework?他应该要解决什么问题?他应该要怎么解决问题?这样解决问题相比已有的来讲好处在哪里?为什么需要这样设计?

代码永远可以改进,问题的核心永远是:他解决了什么问题?值不值得人们去使用?值不值得得到人们的信任?

对 jasl 回复

你现在可以在我的 Github 上看到我的 Autumn 项目了(点击我的头像,进入我的 Github),对于解决什么问题,我最初只是比较喜欢 OOP,然后希望用 OO 模型来解决数据传输问题,我是打算做成数据式 OO 框架。

对 jakitto 回复

可这还是没有解答我的问题啊,在者,为什么要这样做呢?业内是否有相似思路的探索?现在业内是如何做的?你的方法有什么好处?你的愿景是什么?

对 jasl 回复

这个是隐私,我打算的实现,如果你想要知道,可以加我的 QQ(在我的项目下面有备注),私聊来了解。暂时不想公布

对 jakitto 回复

另外,你的代码仓库:https://github.com/Jakitto/Autumn

显然的,你在 Git 的使用上也暴露了严重的问题

对 jakitto 回复

我没兴趣主动去知道,此外,私聊可以告诉我的,显然不是隐私。

对 jasl 回复

我觉得,你们对我是有意见还是什么的,然后整天就说一些:从你的什么什么暴露了问题,然后我觉得你要是觉得哪方面怎么处理,建议,可以直接好好说,但是这样给人的感觉,不是在解决问题,是在引发矛盾了

对 jakitto 回复

首先,我问你的问题你总是用隐私回避啊...

回到我指出你在 Git 使用有严重问题:

如果你真的是在本地使用 Git 管理项目的话,Push 到 Github 仅需添加一个 remote,然后 push 上去

而这是你的提交记录,你的第一次提交产生于一个小时前。

你的代码也是复制过来的。

此外,你的项目并没有包含 .gitignore 文件,导致你要手动删除 .DS_Store,之后,随着你项目复杂,你还会引入更多垃圾文件进入仓库

对 jasl 回复

我在车上,我有.gitignore,估计是刚才没有 add 这个隐藏文件,我知道有这个问题,刚才发现了,我应该先加它的,急着给你们,所以顺序乱了,垃圾文件加进去了

现在社区里越来越多没有意义的撕逼。。。。

对 jakitto 回复

然而这并不是隐藏文件,显然的,git add --all 或者 git add . 都会添加这个文件进 tracking,Xcode 也应该会显示这个文件。此外,你现在的代码仓库里现在也不存在这个文件

对 ForrestDouble 回复

开始还是可以的,后来顾左右而言他已经味道变了

楼主拿 js 跟 ruby 比语法,输定了……

高深莫测

jakitto 关闭了讨论。 06月04日 20:33
jasl 重新开启了讨论。 06月04日 23:17

后来楼主专栏也删评关平了...

jasl 关闭了讨论。 06月04日 23:18
jakitto 重新开启了讨论。 06月04日 23:23
jakitto 关闭了讨论。 06月04日 23:23
jakitto 重新开启了讨论。 06月04日 23:32
jakitto 关闭了讨论。 06月04日 23:32
需要 登录 后方可回复, 如果你还没有账号请 注册新账号