@Los 其实国内大多数论坛都不适合讨论，稍微列举一些我反感的现象吧：
1. 不思考，想当然，随大流。
2. 经常以含沙射影或直接的人身攻击来争论与人格或生物无关的问题。
3. 无法包容主观异见。似乎全世界男人都必须喜欢他的女友，在和其他女人比较时，必须以他的判断标准，必须认为他的女友是最好的。
4. 在辨析不同观点时存在受迫性阅读障碍。具体表现是不去理解对方所要表达的核心思想，而是直接定位到不同观点，不分析上下文，进行断章取义的曲解以满足自己的观点。

所以我只简单回复一下，与Objective-C无关的不想再扯了。

直接从百度百科上copy下来的，我语文不及格，什么意思我看不懂：
直观(perceptual intuition)，通过对客观事物的直接接触而获得的感性认识。
1.用感官直接接受的。
2.形容事物的属性容易辨识。

是否有二义与是否直观没有直接联系。对某些人来说，数学公式并不直观，因为他们可能看不懂某些奇葩的符号，但数学公式是无二义的；同时他们认为语文课文直观易懂，仅管每个人读它时都有自己的理解和认识。

请认清“撒野”是个贬义词，我这里代指我认为不好的coding风格（我主观上的）。如果给我选择，我希望废弃@end，这加重了我的书写负担；我不喜欢隐式return，这是我认为的撒野。对其他人来说，也许和我的看法正好相反，也许认为这根本不重要，可我的标准关你什么事？
我在接触Python的过程中，越来越感受到实现同一件事，在Python允许我做的方式中，简短的方式几乎总比冗长的更优雅，但它不会为了更短而丧失语义上的直观。因为这就是Pythonic，它在不知不觉中就会推荐你使用更简单而直观的方式。我不想说另一门语言如何如何，至少它不符合我的审美观。所以也不必向我这么肤浅的人灌输你的审美观，我没兴趣，也没妨碍和攻击任何人的审美观。

我从来没有说过“lisp可读性高”，而是说“很容易懂”。它的语法非常单纯，知道基本语法后，没什么读不懂的，不会被什么特殊符号和关键字迷惑。
然而易懂并不代表可读性高。四则运算很容易懂吧，我写几百个数进行运算，中间夹杂着各种括号，你认为它可读性高吗？我想至少我不会，人类会以自然段、语句等单位对语义进行拆分、认知和理解，而括号不适合人去定位和拆分，只是对编译器而言可读性高而已。

最后还是那句话，请尊重和尝试理解他人判断的标准，我不会无端抱怨一些肤浅的不满，有精力的话可以看看下文：
http://www.keakon.net/article/918
所以不要像个没人要的姑娘缠着甩她的男人一样，哭着问“为什么不要我，是不是我穿得太花哨了，是不是我性格太随意了，告诉我我哪点不好，我去改啊”。你不需要改变自己，只是需要找到欣赏你的人。

@ssword 我并没否定Ruby这门语言，前面已经说了，它有我欣赏的地方，但也有我不喜之处。我花了半个月时间去学习它，最终还是觉得有更适合我的语言，仅此而已。
感情这东西本来就是主观的，每个人都有自己的理解，我不喜欢你喜欢的歌手，你多半并不会为此感到受伤和中枪。

那个“2天”并不是“学完”，而是尝试了解整个语言的概览。要说完整的学习过程，C++我花了3年，然后停滞了。Python学了2年，仍在继续。可在有所了解之后，往后的学习过程都只是慢慢去深入和拓展而已，我并未在此过程中对某门语言有颠覆性的认识和看法。换句话说，第一印象是很难颠覆的。

语言可以有特性，但我不喜欢晦涩的特性。列表里很多Ruby的特性我没列出来，因为我确实喜欢，例如block，所以你应该看得出什么是我不喜的。
是否新手和我的看法无关，我讨论的是语言是否直观，最直观的当然是自然语言，无需解释。如果一门语言能很容易地让外行人看懂，这便说明它直观。
举例来说，C++中类的成员默认就是私有的，可我看到过的大部分代码规范里都要求显式地写上private关键字。我想基本上初学者也知道它是私有的，可为什么要写上它呢？
同样，你写不写注释对编译器来说完全不在乎，可你为什么还得写上？

换句话说，与其让其他人剥夺我肆意撒野的权利，我宁愿一开始就不给我这个自由。Ruby尝试着去满足更多人的需求（里面能看到不少语言的影子），这或许是很多人喜欢的，但很可惜这种大杂烩不是我想要的。但这只是我喜不喜欢的问题，没有碍着你喜欢的自由。

Lisp并非不直观，相反它很容易懂。真要举例的话应该是perl，充斥着大量的符号，尝试理解它经常会浪费数十分钟的时光。


@Livid 查资料没查出来，只说是把C改造成能用smalltalk风格的对象，也就是消息传递方式吧…
具体有什么好处并不清楚，我还是自己研究吧，问别人总会惹来不必要的争执，倦了。

@jjgod 艰难读完，也许是我没理解透，没看出哪里能优化到比查询虚函数表更快，即便是在缓存的情况下，效率也不可能更高。

@mayokaze 很久没接触Ruby了，举一些我记得的吧：
1.函数默认返回最后一句表达式
2.if、case之类的语句也是表达式，并且有值
3.$、@、@@、=、?、!之类的变量名
4.%w、%q、%Q、%x等语法
5.<=>运算符
我的看法是能减少工作量的就省，但会导致看上去很生涩的就不该省。这点在初学和向不懂这门语言的人解释时非常重要。
你正在使用它，所以你记得它们是很正常的。可当你不再接触它，过个几年回头看看时，是否还记得$@是什么玩意？

发现一篇好文，Philosophy of Each Language这段大致能解明我的疑惑：
http://www.mactech.com/articles/mactech/Vol.13/13.03/CandObjectiveCCompared/

@roamlog 目前我就是不清楚这个历史原因。我不满足于别人都用这个，所以我也用这个。我想的是如果不好用，有什么地方可以改进；如果好用，有什么可以借鉴。


@CupTools 这两门语言我都不喜欢，遗憾的是用Java的人远多于Objective-C，仅管不是UI方面


@Kai 在MFC上浪费过1周左右的时间，然后就再也不去碰微软的东西了。说实话我就喜欢简单的东西，如果一门语言、一个框架或一个库我在一天之内不能基本掌握它（不去涉及较深奥的部分，只作了解），那我就很难下决心再去浪费时间了。

其中当然也有例外，例如初学C时，我也花了约1周的时间去学习基本的语法，可毕竟那时我只算是刚涉足编程。而C++也花了2周，可我也觉得很值。
之后在学Java、C#、PHP、Python、Ruby、JavaScript、Lisp、Lua、ANI和Go时，我没发现有一个需要超过2天的。在初步了解它们后，我才能知道它们的优劣之处，适合做什么，是否合我口味，以及是否值得继续学下去。其中Go让我很受伤，说实话仔细回味起来，除了语法奇葩点，就没太多优点了；当然Ruby才算是其中最复杂的，但至少功能很可爱，只是不喜它不直观的语法。

而在学Objective-C时我也很奇怪，宣称自己是C的超集，扩展出来的语法却让任何一个只懂C的程序员完全看不懂。举例来说，C的函数声明和调用已经是很通用的风格了，作为它的超集，Objective-C却让方法变成了消息传递，然后各种奇葩语法balabala。反正都看不懂，为什么不干脆摆脱C的束缚，更加特立独行一些呢？

我发这帖不是想找语言的岔，我只是想给自己一个学下去的理由，让我知道它还是有很多闪光点的。我纯粹就是想找个玩意打发时间，但我希望不是浪费时间。

@Kai 话是这么说没错，web app甚至只要写网页就行了，可是cocoa的原生语言就是Objective-C。
假如是在Windows上开发，你让Objective-C去使用MFC、WPF，我想也不是能不能的问题，而是傻不傻的问题。
所以这种方面的比较根本就不平等，而我只想关注语言本身的优点。

@roamlog 我想你误会我的意思了。

我希望的是语言能帮助程序员减少无谓的coding，避免潜在的问题。所以一开始接触内存管理时就觉得很奇怪，难道编译器自动retain一下会怀孕么？

我不是反对使用Objective-C，毕竟我还没完全弄懂它，没什么发言权。可我想谁都不希望以复杂的方法去做一件简单的事吧。

回到你的观点，那么Objective-C和C++做C/S应用有什么差别呢？是什么让你觉得Objective-C更加适合app开发这个领域。

我也不想扯什么苹果限制只能用它开发app的事，这和语言本身无关。如果苹果当初只允许你用C++写，@fmfsaisai和@yanyanlong是否就觉得C++比Objective-C好了？

@jjgod 在wiki上看到这个，难道是运行时还能进行优化么？
http://www.mikeash.com/pyblog/performance-comparisons-of-common-operations.html

关于GC，Android的实现好像粒度很大，而且与此同时必须停下所有线程来跑GC，所以必然会卡住渲染。

不过这些我还是等看完Objective-C的实现再研究吧，目前的问题是你们喜欢它吗，用它的好处是什么？
例如我喜欢Python和JavaScript，从语法上可以找到一堆优雅的地方，写起来也惬意和畅快，性能虽差但足以接受。而Objective-C有什么特别吸引人的地方？

发现我又扯到性能上去了，实际上还是一个平衡的问题。

例如C++使用虚函数表，看上去应该比动态类型语言的查询更快，但也丧失了覆盖静态方法的能力。再如template虽然提供了很好的性能，但复杂的语法与duck typing相比必然导致开发效率的低下。

不管怎么说，这几十年发展下来，电脑的速度快了不止千倍，人脑的速度和人类的寿命却没有这么明显的增长，所以就让一切更加动态吧…

@mayokaze 原以为Objective-C会是很静态的语言，以至于我看category时还在怀疑是不是和JavaScript的prototype差不多的东西。查了下资料后发现本质上确实差不多，但这种运行时绑定的特性估计会让它比C++慢。

初看上去Objective-C 2.0更优秀些，不过推出来也都快5年了，还不能用于iOS开发，估计是性能或内存问题更严重吧…

API方式不适合传统的页面。

以V2EX为例，显示一个首页，你需要调用首页主题、当前用户信息、社区运行状态、最热节点、最新节点、最近访问节点和节点导航等API，如果你不是异步调用这些API的话，网络延迟足够让你的用户抓狂了。

如果弄成AJAX，或者facebook的BigPipe，用户就不会感觉被拖慢了，但这明显会让你的应用变复杂。

二次开发明显Discuz!好于PHPWind，结构更加分明，模板和插件数量与后者相比是数量级的优势。

性能说实话我没感觉出什么差异，老版本似乎是PHPWind更快，但较新的版本好像被Discuz!反超了。

管理方面Discuz!最初的配置比较麻烦，而且要找个功能简直像大海捞针。PHPWind这方面上手很快，可以减少很多体力劳动。

容器设为position:relative，要定位的元素设为position:absolute，然后用bottom定位。

回复真多，插句嘴：我认为短而直观的实现总是更为优雅。Python中提供了这个功能，如果你认为用它实现最简单，就不要怀疑地去使用它。

例如我在YUI里就用了getattr：
https://bitbucket.org/keakon/yui/src/4adaf38a3581/yui.py#cl-1272

web.py也用了这种方法：
https://github.com/webpy/webpy/blob/master/web/application.py#L633

否则得像webapp一样写很多if..else：
http://code.google.com/p/googleappengine/source/browse/trunk/python/google/appengine/ext/webapp/__init__.py?r=142#514

metaclass和decorator我一般只用来隐藏实现，让使用者无需关注其内部的实现。而现在的问题是你开放的这些接口本来就是用来调用的，不应该由被调用者强行注入调用者。
这也是我觉得用decorator来标记一个handler的不妥之处：传统的url mapping方式你可以很一目了然地知道哪些url映射到哪个handler了；而像Uliweb那样写个@expose的话，你得找到所有的handler才能确定这些映射关系，并且还得关注handler的定义顺序和import的顺序。
而这一切并没有带给你任何好处：逻辑更复杂了，阅读更困难了，维护更吃力了。


最后说下那个help的例子，你不觉得使用decorator的实现导致help函数与其他函数之间的耦合度增加了么？
明明其他函数已经开放了__doc__这个属性了，却还要强迫它们维护help函数所需的_actions列表。

如果定义一个Helper类，遍历自身的方法，用getattr取它们的__doc__，就可以少写一个函数、一个列表和多处@action。并且，如果这个类被继承了的话，扩展它的人也不需要写@action来保证help()仍能正常工作。假如你哪天觉得action这个名字不好，需要重命名时，也不需要各处去查找替换@action。

当然，这个例子如果用metaclass实现的话耦合度没有这么高。但在继承时如果不想展示子类的某几个方法，却发现子类的metaclass必须继承父类的metaclass；而如果有多重继承和多个元类则会更复杂。
虽然这种情况很极端，但你不觉得元类会把实现变得更加抽象么？回过头来想想，它本来不是个很简单的反射就直截了当能完成的事么？

头一次看到拿字符串比较的，提醒一下：'2' > '1001'

更新缓存很麻烦，而且很多浏览器的提示很蛋疼，好像被攻击了一样…

我觉得是gears退化后的产物…

try: f = getattr('funcname')
except AttributeError: ...
else: f(*args)

但是不需要全屏吧，很多网页大了不好看