发现一篇好文，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)

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

@myrual bitbucket对于5人以下的项目（包括私有项目）免费，无空间限制

泪流满面的神器，就是稍微贵了点。Guido因为是在做开源项目，所以可以申请open source project license的。