Ruby正在变得越来越受欢迎,主要来自Ruby on Rails的影响,但感觉它正在挣扎于青春期.Ruby和Smalltalk之间有很多相似之处 - 磁悬浮是一个证明.尽管有一个更不寻常的语法,Smalltalk拥有所有(如果不是更多)Ruby的面向对象的美.
从我所看到的,Smalltalk似乎有Ruby击败:
成熟度(1970年代开发)
稳定性
商业支持
分布式源代码控制(理解代码结构,而不仅仅是文本差异)
VM的几种实现
跨平台支持
在海边的Web框架作为一个强有力的替代选择到Rails
看起来Ruby只是重新发明轮子.那么,为什么Ruby开发人员不使用SmallTalk？Ruby拥有Smalltalk的不是什么？
记录:我是一个对Smalltalk几乎没有经验的Ruby人,但我开始想知道为什么.
编辑:我认为GNU Smalltalk已经解决了易于编写脚本的问题.据我了解,这允许您在常规旧文本文件中编写smalltalk,并且您不再需要在Smalltalk IDE中.然后,您可以运行脚本:
gst smalltalk_file
ConcernedOfT.. 88
我更像是Python用户而不是Ruby用户,但是出于同样的原因,同样的事情也适用于Ruby.
Smalltalk的体系结构有点孤立,而Python和Ruby是从头开始构建的,以便于集成.Smalltalk从未真正获得过Python和Ruby所拥有的混合应用程序支持,因此'smalltalk作为嵌入式脚本语言'的概念从未流行起来.
顺便说一句,Java并不是与其他代码库接口最简单的东西(JNI相当笨拙),但这并没有阻止它获得思想共享.IMO接口论证很重要 - 嵌入的简易性并没有损害Python - 但是这个论点只有适度的权重,因为并非所有应用程序都需要这种能力.此外,Smalltalk的后续版本确实解决了这个问题.
大多数主要的smalltalk实现(VisualWorks,VisualAge等)的类库很大,并且具有相当陡峭的学习曲线的声誉.Smalltalk中的大多数关键功能都隐藏在类库中的某个地方,甚至是流和集合等基本内容.语言范式对于不熟悉它的人来说也是一种文化冲击,浏览器呈现的程序的零碎视图与大多数人习惯的完全不同.
总体效果是,Smalltalk因难以学习而获得(有些当之无愧)的声誉; 成为一名非常精通的Smalltalk程序员需要花费大量的时间和精力.Ruby和Python更容易学习,并且可以让新程序员快速掌握.
从历史上看,主流的Smalltalk实现非常昂贵,并且需要使用奇特的硬件来运行,这可以从1983年的net.lang.st80发布.Windows 3.1,NT和'95以及OS/2是主流硬件上的第一个大众市场操作系统,能够支持具有良好本机系统集成的Smalltalk实现.以前,Mac或工作站硬件是能够有效运行Smalltalk的最便宜的平台.一些实现(特别是Digitalk)很好地支持了PC操作系统并且确实成功地获得了一些牵引力.
但是,OS/2从未如此成功,Windows直到20世纪90年代中期才获得主流认可.不幸的是,这恰好与作为平台的Web的兴起和Java背后的大规模营销推动相吻合.在20世纪90年代后期,Java抓住了大部分的思想共享,使Smalltalk成为了一个同样的人.
Ruby和Python在更传统的工具链中工作,并没有与特定的开发环境紧密耦合.虽然我使用的Smalltalk IDE已经足够好了,但我使用PythonWin进行Python开发很大程度上是因为它有一个很好的编辑器,它具有语法高亮功能并且不会出现问题.
但是,Smalltalk被设计用于IDE(事实上,Smalltalk是原始的图形IDE),并且仍然具有一些不被其他系统复制的好功能.使用突出显示和"显示"测试代码仍然是我在Python IDE中从未见过的非常好的功能,尽管我不能代表Ruby.
Smalltalk来到网络应用方面有点迟.像VisualWave这样早期的努力从来都不是非常成功,直到Seaside出现了一个体面的Web框架才得到Smalltalk圈子的认可.与此同时,Java EE已经有了一个完整的验收生命周期,从狂热的粉丝们开始推广它,最后变得厌倦并转向Ruby; -
具有讽刺意味的是,Seaside开始在认知中获得一点思想,所以我们可能会发现Smalltalk骑了这个重新流行起来.
话虽如此,一旦你弄清楚如何驾驶它,Smalltalk就是一个非常好的系统.
我更像是Python用户而不是Ruby用户,但是出于同样的原因,同样的事情也适用于Ruby.
Smalltalk的体系结构有点孤立,而Python和Ruby是从头开始构建的,以便于集成.Smalltalk从未真正获得过Python和Ruby所拥有的混合应用程序支持,因此'smalltalk作为嵌入式脚本语言'的概念从未流行起来.
顺便说一句,Java并不是与其他代码库接口最简单的东西(JNI相当笨拙),但这并没有阻止它获得思想共享.IMO接口论证很重要 - 嵌入的简易性并没有损害Python - 但是这个论点只有适度的权重,因为并非所有应用程序都需要这种能力.此外,Smalltalk的后续版本确实解决了这个问题.
大多数主要的smalltalk实现(VisualWorks,VisualAge等)的类库很大,并且具有相当陡峭的学习曲线的声誉.Smalltalk中的大多数关键功能都隐藏在类库中的某个地方,甚至是流和集合等基本内容.语言范式对于不熟悉它的人来说也是一种文化冲击,浏览器呈现的程序的零碎视图与大多数人习惯的完全不同.
总体效果是,Smalltalk因难以学习而获得(有些当之无愧)的声誉; 成为一名非常精通的Smalltalk程序员需要花费大量的时间和精力.Ruby和Python更容易学习,并且可以让新程序员快速掌握.
从历史上看,主流的Smalltalk实现非常昂贵,并且需要使用奇特的硬件来运行,这可以从1983年的net.lang.st80发布.Windows 3.1,NT和'95以及OS/2是主流硬件上的第一个大众市场操作系统,能够支持具有良好本机系统集成的Smalltalk实现.以前,Mac或工作站硬件是能够有效运行Smalltalk的最便宜的平台.一些实现(特别是Digitalk)很好地支持了PC操作系统并且确实成功地获得了一些牵引力.
但是,OS/2从未如此成功,Windows直到20世纪90年代中期才获得主流认可.不幸的是,这恰好与作为平台的Web的兴起和Java背后的大规模营销推动相吻合.在20世纪90年代后期,Java抓住了大部分的思想共享,使Smalltalk成为了一个同样的人.
Ruby和Python在更传统的工具链中工作,并没有与特定的开发环境紧密耦合.虽然我使用的Smalltalk IDE已经足够好了,但我使用PythonWin进行Python开发很大程度上是因为它有一个很好的编辑器,它具有语法高亮功能并且不会出现问题.
但是,Smalltalk被设计用于IDE(事实上,Smalltalk是原始的图形IDE),并且仍然具有一些不被其他系统复制的好功能.使用突出显示和"显示"测试代码仍然是我在Python IDE中从未见过的非常好的功能,尽管我不能代表Ruby.
Smalltalk来到网络应用方面有点迟.像VisualWave这样早期的努力从来都不是非常成功,直到Seaside出现了一个体面的Web框架才得到Smalltalk圈子的认可.与此同时,Java EE已经有了一个完整的验收生命周期,从狂热的粉丝们开始推广它,最后变得厌倦并转向Ruby; -
具有讽刺意味的是,Seaside开始在认知中获得一点思想,所以我们可能会发现Smalltalk骑了这个重新流行起来.
话虽如此,一旦你弄清楚如何驾驶它,Smalltalk就是一个非常好的系统.
当我早上离开家去上班时,我经常会挣扎着决定从我的车道左转或右转(我住在街道中间).无论哪种方式都会让我到达目的地.一种方式引导我到高速公路,根据交通情况,可能会让我最快到办公室.至少部分时间我开得非常快,我很有可能在上班的路上看到一两个漂亮的女孩:-)
另一种方式让我可以沿着一条非常迷人,多风的后面道路行进,并有完整的树木覆盖.这条道路非常令人愉快,而且这两种方法肯定更有趣,虽然这意味着我会比我走高速公路后到办公室.每种方式都有其优点.在我匆忙的日子里,我会经常走高速公路,虽然我可能遇到交通,但我也增加了发生事故的机会(如果我不小心匆忙).其他日子我可以选择木质路径,开车,欣赏风景,意识到我迟到了.我可能会尝试加快速度,提高自己获得机票或造成事故的机会.
两种方式都不比另一方好.他们每个人都有自己的利益和风险,每个人都会实现我的目标.
我认为你的问题有点遗漏了这一点. 你不应该选择,你应该学习它们!
如果你真的能够选择下一个框架(vm,基础设施),那么你需要决定使用什么,并且可以从你的应用程序的意图来看,从优缺点中提出具体问题.
我曾经使用过smalltalk(喜欢它)和ruby(喜欢它).
在家里或开源项目中,我可以使用我喜欢的每种语言,但在工作时我必须采用.
我开始使用ruby(在工作中),因为我们需要一些脚本语言,在solaris,linux和windows(98,2000,xp)下表现得或多或少.当时Ruby对于普通乔来说是未知的,并且没有任何轨道.但它很容易卖给所有参与者.
(为什么不是python？真相？我曾经花了一个星期的时间寻找一个错误,当一个终端将我的空间转换为一个标签并且打算弄乱了)时发生的错误.
所以人们开始越来越多地使用红宝石编码,因为它非常轻松,享受而不是天空中的云.
保罗格雷厄姆总结了这一点
当然,大多数人都不会根据自己的优点选择编程语言.大多数程序员被告知其他人使用的语言.
和
为了吸引黑客,语言必须适合编写他们想要编写的程序.这或许意外地意味着它必须有利于编写一次性程序.
当在Lisp的土地上尝试用smalltalk替换LISP时
Ruby的图书馆,社区和动力都很好
因此,如果LISP仍然比Ruby更强大,为什么不使用LISP呢？对LISP编程的典型反对意见是:
没有足够的图书馆.
我们不能聘请LISP程序员.
在过去的20年里,LISP无处可去.
这些并非压倒性的反对意见,但它们当然值得考虑.
和
现在,在强大的语言和流行的语言之间做出选择,选择强大的语言可能是非常有意义的.但如果力量的差异很小,那么受欢迎会有各种各样的好处.2005年,在选择LISP而不是Ruby之前,我会想很久很难.如果我需要优化的代码,或者作为完整编译器的宏,我可能只会这样做.
我会说相反:Smalltalk语法是最简单和最强大的编程语言语法之一.
这些语言非常相似.解释这个问题的浅薄方法是将Ruby称为Smalltalk封面乐队.更合理的解释是,Smalltalk的封闭系统隔离了它,而Ruby参与Unix生态学以及从太阳下的每种语言中挪用特征的习惯使它具有无限温和的采用曲线,并且与Git等kickass工具轻松集成.
Giles Bowkett
猜猜是谁说的？(引用很接近,也许并不准确):"我一直以为Smalltalk会击败Java.我只是不知道它是否会被称为'Ruby'."
击鼓 ....
...
答案是肯特贝克
Stephane Ducasse在这里有一些很棒的Smalltalk书籍:
http://stephane.ducasse.free.fr/FreeBooks.html
因此,尽管Smalltalk社区并不像Ruby和Rails社区那样多产,但仍然有一些很大的帮助.
Ruby拥有Smalltalk的功能是什么？
主要平台(IronRuby和jRuby)提供的大量现有支持,丰富了图书馆的集合
像戴夫·托马斯这样的传教士多年来一直在全国各地巡回演讲,传播他们语言的福音.我在Java会议上看到Dave 说他不懂Java而且他更喜欢Ruby.
书架上现有的强大房地产
Ruby的创建者曾表示他会考虑程序员:Ruby的语法似乎具有这种禅宗的吸引力.这很难确定,但似乎激起了粉丝们的兴趣.
像Giles 这样富有创意,充满活力的演示文稿,以及获得大家共享
我认为你的观点很好.正如朋友曾经说过的那样,Ruby可能是"新瓶中的旧酒",与Smalltalk相比.但有时新瓶子很重要.葡萄酒必须在正确的时间出现在正确的地方.
甘拜下风.我花了一年时间检查Ruby并做了一些小项目,看看我喜欢它.我想我是一个Smalltalk偏执狂,因为每次我坐下来与Ruby合作我都会叹气并且想"我真的宁愿在Smalltalk中这样做".最后我放弃了,回到了Smalltalk.现在我更快乐了.更快乐的是.
当然这引出了一个问题,"为什么？".没有特别的顺序:
因为IDE吹走了我曾经使用过的任何东西.这包括从IBM大型机上的ISPF到Microsoft的Visual(.*)的一堆平台,包括Visual Basic 4-6,Visual C++(各种化身),Borland的Turbo Pascal和后代(例如Delphi)等东西,以及DEC的东西.字符模式和X-Windows下的机器.
因为图像是一个美丽的居住地.我可以在那里找到我想要的东西.如果我无法弄清楚如何做某事,我知道图像中的某个地方就是我要做的事情的一个例子 - 我所要做的就是找到它直到找到它.并且它是自我记录的 - 如果你想看到某些东西如何工作的细节,你只需在你感兴趣的类上打开一个浏览器,看看方法,它是如何工作的.(好吧,最终你会点击一个叫原语的东西,然后它就是"这里有龙",但它通常可以从上下文中理解).在Ruby/C++/C中可以做类似的事情,但它并不容易.容易更好.
语言最小且一致.三种消息 - 一元,二元和关键字.这也描述了执行的优先级 - 首先是一元消息,然后是二进制消息,然后是关键字消息.使用括号帮助解决问题.Dang语法很少,真的 - 这些都是通过消息发送完成的.(好吧,赋值不是消息发送,它是一个运算符.所以是'return'运算符(^).块由方括号对([])包围.可能是其中一个或两个"魔术"位,但是很少...).
块.是的,我知道,他们在Ruby(以及其他人)中存在,但是,它实际上无法在不使用它们的情况下在Smalltalk中编程.你被迫学习如何使用它们.有时被迫是好的.
面向对象的编程没有妥协 - 或者替代方案.你不能假装自己在做"物体",同时还要做同样的旧事.
因为它会拉伸你的大脑.我们已经习惯的舒适结构(if-then-else,do-while,for(;;)等)不再存在,所以你必须学习新的东西.所有上述(以及更多)都有等价物,但你必须学会以不同的方式思考.不同是好的.
另一方面,这可能只是一个自大型机统治地球以来一直在编程的人的乱像,我们不得不步行五英里通过暴风雪,上坡两路上行,电脑用甜甜圈记忆.我没有反对Ruby/Java/C/C++ /,它们在上下文中都很有用,但是给我Smalltalk或者给我......好吧,也许我应该学习Lisp或Scheme或...... :-)
Smalltalk:人们转发ifTrue:[think] ifFalse:[not thinking]
Ruby:除非思考倒退,否则人们会认为是前锋
1)Smalltalk的消息类似RPN的控制流程就像Lisp一样 - 它是常规的,但很酷但人们很奇怪.
2)Ruby允许人们使用人们说话的惯用语言来编写代码 - 除非有理由不这样做.
更新重写了Smalltalk示例实际上是更合法的代码..
Ruby是目前的流行语言.现在推销使用它构建的软件比70年代开发的语言更容易.
社区!Ruby,特别是Rails拥有如此优秀的社区.当搞乱smalltalk时,似乎没有关于Smalltalk的屏幕演员,文章,博客文章等.
你在第一行回答了这个问题:"Ruby越来越受欢迎"
Ruby 有很多有趣的模块,项目等.
如果你在Ruby中做某事有困难,那么在某处寻求帮助将是微不足道的.
Ruby现在安装在很多计算机上(默认包含在OS X上,很多Linux发行版,还有很好的Windows安装程序) - 我没有看到在我使用的任何机器上默认安装了smalltalk.
我会说一种语言是否优于另一种语言是无关紧要的..作为一个例子,PHP可能不是有史以来"最好的"语言,但我仍然会考虑使用Ruby on Rails(一种"更好"的创建工具)网站)因为它如此普遍.
基本上,语言的具体优点和缺点远不如周围的一切 - 即社区.
Ruby(或任何其他语言)比Smalltalk(或任何其他语言)更受欢迎,因为我们生活在一个混乱的世界中.以机智:
来自戴夫·托马斯本人,"[关于如何在十分钟内建立一个博客"的视频之后...... Ruby从一个不错的小利基语言变成了'一种你在其中编写Rails应用程序的语言'"(Ruby Conference) 2010年主题演讲).
早期的Smalltalk供应商收费令人望而却步
Smalltalk,因为它是30年前发明的(超过它的时间),许多人认为它是一种古老的"死"语言(如FORTRAN)
公司认为Smalltalk具有竞争优势,因此他们隐藏了它的用途
虽然OO功能的语言类似,但Smalltalk的杀手优势是实时,开放的环境(被误解的"图像").在您查看Smalltalk编程示例后,争论就结束了.
对我而言,它不仅仅是Ruby所拥有的,而是Ruby所没有的.而它没有的是对VM和完整环境的需求.
Smalltalk很棒 - 它是我学习OO概念的地方,但为了方便使用,我选择了Ruby.我可以在我最喜欢的编辑器中编写Ruby代码并从命令行运行它.
所以,对我而言,这就是我选择Ruby over Smalltalk的原因.
我想每个与Ruby合作过一段时间的人都会认识到它对Smalltalk的沉重负债.作为其中一个人,我喜欢Ruby over Smalltalk？我认为从严格的语言角度来看,这是糖.Ruby故意是一种非常语法化的语言,而Smalltalk是一种非常语法的语言.Ruby本质上是具有Perlish语法糖的Smalltalk对象模型.我碰巧喜欢糖,并发现它使编程更有趣.
你可以很容易地找到一份Ruby工作.虽然我真的很喜欢Smalltalk,但几乎不可能进入Smalltalk利基市场.其中有一些工作,但如果你在它受欢迎时没有进入它现在几乎是不可能的.
所有其他原因都显得微不足道,因为你需要花费大量时间,专注于真正的工作来正确学习语言.如果你不是独立富有的,那么最好的方法就是在工作中接触它.
京公网安备 11010802040832号 | 京ICP备19059560号-6 