p*****2
发帖数: 21240 | 1 首先感觉Go受到C，Java，Javascript，Scala／Haskell的影响，但是从精神上主要是C
的影响，这也是人所共知的，所以确实是个升级版的C语言。看得出来作者是较强烈
against Java的，这点比较赞。JS和Scala／Haskell的影响主要是functional和一些语
法特性上，但是显然functional的影响比较浅显，甚至还不如对Java8的影响大。
先说说优点
1. 并发设计的十分强大，在我用过的几种语言中绝对是排行首位，也是go的最大卖点。
2. 简化了OO，抛弃了OO很多糟粕。
3. 简单易学，大众语言, 适合团队作战。
4. 确实在不少地方对C语言进行了改良。
再说说缺点
1. 最大的问题就是error handling部分，延续了C的处理方式，在语法部分尝试去简化
，但是感觉效果其实并不是很明显。
2. 因为＃1，使得一个函数里会出现很多的return，可读性比较差。但是由于加入了
defer，使得问题没有在C里面那么严重，习惯了也不是不能接受。
3. goto感觉被阉割了，C语言里的一些技巧很难使用，感觉goto的用处没那么大了。当
然这也不是坏事，goto本来就应该少使用，但是由于error handling的繁琐，不能通过
goto来解决还是比较郁闷。
4. 保留pointer比较奇怪，不过也不是不能接受。
5. 没有generics这个，我现在感觉还没给我带来明显的障碍。
如果不谈并发，我个人不觉得go的productivity高，当然比C，Java高那是肯定的。但
是还有很多可以提供更高的productivity。但是并发的简化这块可以明显提升
producitivity，所以如果写大并发应用的话，还是个很好的选择。 |
z****e
发帖数: 54598 | 2 go,java这些都是用c++的人用吐血后作出的东西
可见c++有多糟糕
教主都废弃了c++，而选择了obj c
obj c多冷门的东西，教主情愿用这个，都不愿意选择c++啊
swift之后就更没c++啥事了，c++一点一点退出历史舞台 |
p*****2
发帖数: 21240 | 3
大牛说的很对。C++根本就没有解决什么问题。C的很多问题，其实IDE都可以解决，不
需要C++，当然当时的IDE确实太弱了。
【在 z****e 的大作中提到】
: go,java这些都是用c++的人用吐血后作出的东西
: 可见c++有多糟糕
: 教主都废弃了c++，而选择了obj c
: obj c多冷门的东西，教主情愿用这个，都不愿意选择c++啊
: swift之后就更没c++啥事了，c++一点一点退出历史舞台
|
z****e
发帖数: 54598 | 4 作为论据，我找到了中文的翻译，但是那个youtub链接失效了
Go语言之父谈Go：大道至简
时间：2012-07-05 15:40 作者：王然
导读：这篇文章是Google首席工程师、Go语言之父Rob Pike自己整理的6月21日在旧金
山给Go SF的演讲稿。Rob提到：Go语言本是以C为原型，以C++为目标设计，但最终却大
相径庭。值得一提的是，这3门语言都曾当选TIOBE年度语言。
几个礼拜之前我被问到：“对于Go语言，最令你惊讶的是什么？”当时我就明确地给出
了答案：“虽然我希望C++程序员能够使用Go作为替代拼，但实际上大部分Go程序员都
是从Python和Ruby转过来的，其中却少有C++程序员。”
我、Ken以及Robert都曾是C++程序员，在我们编写软件时觉得应该设计一门更适合解决
这个问题的编程语言。奇怪的是，其他程序员似乎却不关心。
今天我将说说是什么让我们决定创造Go语言的，及其出乎意料的结果。这里我谈的更多
的会是Go而不是C++，所以即使你不懂C++也没关系。
主旨可以简单地总结为：你更同意Less is more还是Less is less？
这里有一个真实的故事。贝尔实验室中心本来分配3位数字作代号：物理搜索是111，计
算科学搜索是127，以及等等。20世纪80年代，随着对搜索的进一步理解，我们认为有
必要新增数位以更好地特征化工作，于是我们的中心就成了1127。
Ron Hardin半开玩笑半正经地说如果我们真的更好地理解了世界，我们已经可以去掉一
个数位，把127变成27。当然，管理人员并没有相信这个玩笑，当然Ron也没指望他们会
相信，但我认为这很有哲理。有时候少意味着更多，你理解得越深，就能越干练。
请记住这个想法。
回想2007年9月的时候，我正在为Google庞大的C++程序做一些比较琐碎但是核心的工作
（对，就是你们都用过的那个！），我工作在Google庞大的分布式编译集群上都需要花
45分钟。之后有几个C++标准委员会的Google员工为我们做了个演讲，他们给我们介绍
了下C++0x（现在被叫做C++11）里会有什么新东西。
在那一个小时的演讲中，我们大概听到了约35种计划中的新特性。当然实际上还有更多
，但是在那次演讲中我们只听到了35种左右。有的特性比较小，当然演讲中所提到的任
何一种特性都可以称得上标志性的：有的比较精妙，但是很难理解，像右值引用（
RValue Reference）；其它的很有C++的特色，例如variadic模板；还有一些只是一些
相当疯狂的，一如用户定义文字（user-defined literal）。
这时候，我问了自己一个问题：C++委员会真的认为C++的特性还不够多？当然，不同于
Ron的玩笑，简化这门语言必是一门更大的成就！也许这很可笑，但是请把这个想法记
在心里。
在那个C++演讲的几个月之前，我做了一个演讲（你可以在YouTube上看到），是关于一
个我在上世纪80年代开发的玩具性的并发性语言。那个语言叫作Newsqueak，也就是Go
的前身。
我做那个演讲是因为我在Google工作的时候忘记了一些Newsqueak里的好想法，现在回
顾一下。我确信它能简化服务器端代码编写，而且对Google也有好处。
实际上我也试过把这个想法加入C++，但是失败了。把并发操作和C++控制结构整合到一
起非常困难，反过来也意味着即使侥幸成功收益也会非常小。
不过C++0x的演讲让我又重新思考了一遍。新的C++内存模型使用了原子类型，这让我很
困扰，我认为Ken和Robert肯定也不喜欢。感觉把这样一个如此细节的功能加入已经超
负载的类型系统里并不是一个明智的选择。这看起来也很目光短浅，因为硬件也可能在
接下来的十年里发生明显的变化，所以把语言和当今的硬件捆绑地太紧不见得是一个正
确的选择。
演讲结束后，我们又回到了办公室。我又开始了编译工作，我转过椅子好面向Robert，
然后开始问一些关键性的问题。在编译结束之前，我们说服了Ken，决定一起做一些事
情。我们再也不想用C++了，同时也很希望能在写Google的代码时能用到并行性特性。
“大代码”问题也是一个需要关注的问题，但我们最终决定这个问题最后再解决。
然后我们找了块白板，在上面写下希望能有哪些功能。这里我们只关注大的方面，语法
和语义学这些细节性的东西先放到一边去。
之后我们在邮件上交流，这里是内容摘选：
Robert：以C语言为原型，修补部分明显的缺陷，去掉垃圾功能，添加一些缺失的功能。
Rob：命名为“Go”，好处有很多，这名字非常简短，容易拼写。工具可以叫做：goc、
gol、goa。如果有可交互的调试器/解释器也可以简单地叫它“Go”，后缀名用 .go。
Robert：定义空接口语法：interface{}。所有接口都通过这个实现，因此可以用它代
替void*。
我们没有一开始就设计出所有的功能，之后花了一年的时间才确定了array和slice功能
，不过也有很多语言的特色在最初几天就已经确定下来的。
注意：Robert说要以C语言为原型，而不是C++！但实际上我们也并不是真的从C开始，
只是从中借了部分内容，比如运算符、括号和几个相同的关键字。当然为了让它成为最
适合我们的语言，我们从所有了解的语言里都借取了一些特性。
最后结果毫无疑问跟C或C++大不相同。以下是Go从C和C++简化的功能：
规范的语法（不需要符号表来解析）
垃圾回收（独有）
无头文件
明确的依赖
无循环依赖
常量只能是数字
int和int32是两种类型
字母大小写设置可见性（letter case sets visibility）
任何类型（type）都有方法（不是类型）
没有子类型继承（不是子类）
包级别初始化以及明确的初始化顺序
文件被编译到一个包里
包package-level globals presented in any order
没有数值类型转换（常量起辅助作用）
接口隐式实现（没有“implement”声明）
嵌入（不会提升到超类）
方法按照函数声明（没有特别的位置要求）
方法即函数
接口只有方法（没有数据）
方法通过名字匹配（而非类型）
没有构造函数和析构函数
postincrement（如++i）是状态，不是表达式
没有preincrement(i++)和predecrement
赋值不是表达式
明确赋值和函数调用中的计算顺序（没有“sequence point”）
没有指针运算
内存一直以零值初始化
局部变量取值合法
方法中没有“this”
分段的堆栈
没有静态和其它类型的注释
没有模板
没有异常
内建string、slice和map
数组边界检查
因为有这么多功能的简化，我相信Go比C和C++更有表现力。Less can be more！
但是也不能全部丢弃。你需要把想法分为模块，例如：类型如何工作、能够实际上良好
运行的语法以及有助于保证类库交互的东西。
我们也加入了一下C和C++里没有的东西，比如slice和map、复合文本（composite
literal）、顶层文件表达式（这是一个大问题，但经常被忽视）、映射（reflection
）、垃圾回收等等，我们还非常自然地加入了并发性。
很明显还缺少了类型层次结构，这让我很生气。
在Go语言的首次启航中，我得到了一个“我不能在没有泛型的环境下工作”的反馈，这
真是一个奇怪的言论。
平心而论，我觉得他可能是因为在C++里用惯了STL的原因。从字面意思来看，这就是说
着写一个int list或者string map对他来说是一个非常大的负担。我不会在这种奇怪的
问题上花太长的时间，所以这种需要泛型支持的也一样。
但更重要的是，只有类型是用来解决这样的问题的，既不是多态函数（polymorphic
function）也不是语言原语（language primitive）或者其它类型的帮助，只有类型！
这就是卡住我的的细节。
从C++和Java转向Go的程序员很怀念使用类型编程的方式，特别是继承和子类这样的概
念。也许关于“类型”我只是一个门外汉，但我真没发现模板有什么好处。
我已故的朋友Alain Fournier曾告诉我，他认为学术工作最基本的要求就是分工。你知
道吗？类型层次也只是一种分类法。你需要决定什么东西封装在什么里面，每个对象的
父类型是什么？到底是A继承B还是B继承A？可排序数组究竟是用来排序的数组还是一个
通过数组实现的排序器？如果你坚信类型决定设计那这个就是必须理清的问题！
我认为这是一个对于编程的荒谬的思考方式。真正重要的是这些类能为你做什么而不是
它们之间是什么关系！
当然这就是Go语言里接口的关系，不过这只是部分规则，Go语言的设计理念实际上比这
还要复杂得多。
如果说C++和Java是关于类的层次和分类，那么Go的核心思想就是组合（composition）。
Doug McIlroy，Unix管道原理的最终发明者，在1964年写道：
当我们需要将数据以另一种方式整合到一起时，我们需要一些类似花园里软管的方法将
程序耦合在一起，这也和IO的处理方式一样。
同样Go也是这样——Go取自这一思想，但是更进一步——它就是一个组合与联结的语言。
举个例子：接口提供了组合的方式，只要实现了方法M就可以直接放在那儿，无论它是
什么都会很合适。
另一个例子是关于并发性如何给我们带来独立执行计算能力。
Go有一个非常不同寻常但是很简单的类型组成方式：嵌入。这些组合技术正是Go的独特
之处，与C++或者Java程序截然不同。
虽然这与Go语言的设计不是很相关，但我还是想说：Go是为大型程序设计的，需要大的
团队编写和维护。
大型程序设计，通常被认为是C++和Java的领域。我认为，这只是一个历史遗留问题，
或许还是一个产业事故，但普遍被认为这和面向对象设计有关。
我不赞同这个观点，大软件需要确定的理念，但强依赖管理、整洁的接口、抽象化以及
优秀的文档工具这些更为重要！不幸的是，这些没一个是C++的强项（不过这点Java明
显就好得多）。
当然，现在还不能确定，因为用Go语言编写的程序还不够多，但我相信Go会成为一个非
常好的大型程序编程语言。时间会证明一切！
现在，回到我们讲话的中心：
为什么Go从头到尾都是以C++为目标来设计的却无法吸引到C++程序员？
Joke认为，这可能是因为Go和C++的设计理念相差甚大吧。
C++希望所有解决方案都能很容易得到/使用。我在C++11 FAQ（常见问题）上看到了这
句话：
C++能够优美地、灵活地并且零成本地表现出抽象事物的能力，相比专门编写的代码
要高效很多。
这种思考方式和Go的运转方式并不一样 。零成本不是目标，至少零CPU成本不是。Go的
目标是解放程序员！
Go并没有包罗万象，你不要期待它什么都有，你也无法精确地控制每一个细节。例如：
Go没有RAII，但是你可以使用一个垃圾清理器做替代，虽然你甚至无法使用内存释放函
数。
你可以从Go中得到很多易于理解但是强大的工具集来组合出问题的解决方案。它跟别的
语言比起来也许没有那么快或者精致，但肯定写起来更简单、读起来更容易，也更易于
理解，也许还更安全。
从另一个角度看，Go肯定更加简化：
Python和Ruby程序员转向Go是因为他们不需要学更多的关心却可以获得更好的性能，甚
至还可以使用并发特性。
C++程序员不愿意转向Go是因为他们竭尽全力只为了对自己的程序的完全掌控，并不希
望这样改变。对于他们，软件并不仅是完成工作，而是做好工作。
现在的问题在于，如果Go成功了，会颠覆他们的世界观。
而且我们应该在一开始就注意到：对C++11新特性感兴趣的人是不会对一个功能如此简
洁的语言感兴趣的，即使它能完成更多的任务。
原文链接：commandcenter.blogspot.com
本文为CSDN编译整理，未经许可不得转载。如需转载请联系[email protected]
/* */。 |
z****e
发帖数: 54598 | 5 c++程序员最搞笑的就是
每次都大谈c是如何如何地好，java如何如何地不好
而完全忘记了，c++之所以被弄出来
就是想在c上加入oop的功能
(java+c)/2=c++
c++是介于c和java中间的一个东西
如果java如何如何糟糕，c++岂不是朝这个方向上迈出的愚蠢的一步？
笑死人了
而真正朝着另外一个方向迈出一步的是go
go=c--++，因为先丢掉c的一些features，然后再加入一些features以替换c++
java是什么呢？java最初一个版本的名字就叫做c++--
本质上说，java和go都是几个天才不满意c++过多features带来的混乱而创造出来的语言
这两个语言的共性就是，敢于对一些导致混乱的features下手
而不是像教徒一样膜拜某种语言，该弄死时候直接弄死掉，壮士断腕
奴隶失去的只是锁链，得到的却是整个世界，新世界欢迎你
让时间埋葬那些还活在套子里的人吧
go的作者曾经这么说过
大软件需要确定的理念，但强依赖管理、整洁的接口、抽象化以及优秀的文档工具这些
更为重要！
不幸的是，这些没一个是C++的强项（不过这点Java明显就好得多）。
关于大软件的几个要素，java是这么解决的
依赖管理，强制oop
整洁的接口，jdbc,jvm都是统一的接口，整个j2ee都是一套完整的接口定义
抽象化，干掉了pointer，有了gc，跨平台这些，你可以不再被os，内存这些所困扰
优秀的文档工具，javadoc，自动生成文档，vert.x的文档也相当好，清晰明了 |
z****e
发帖数: 54598 | 6 C++程序员不愿意转向Go是因为他们竭尽全力只为了对自己的程序的完全掌控，并不希
望这样改变。对于他们，软件并不仅是完成工作，而是做好工作。 |
l******t
发帖数: 55733 | 7 都是干货啊。
GO并发怎么好，给个例子？
是C
点。
【在 p*****2 的大作中提到】
: 首先感觉Go受到C，Java，Javascript，Scala／Haskell的影响，但是从精神上主要是C
: 的影响，这也是人所共知的，所以确实是个升级版的C语言。看得出来作者是较强烈
: against Java的，这点比较赞。JS和Scala／Haskell的影响主要是functional和一些语
: 法特性上，但是显然functional的影响比较浅显，甚至还不如对Java8的影响大。
: 先说说优点
: 1. 并发设计的十分强大，在我用过的几种语言中绝对是排行首位，也是go的最大卖点。
: 2. 简化了OO，抛弃了OO很多糟粕。
: 3. 简单易学，大众语言, 适合团队作战。
: 4. 确实在不少地方对C语言进行了改良。
: 再说说缺点
|
p*****2
发帖数: 21240 | 8 go 的异步是go来帮你做
而其他语言都需要程序员来take care of
现在的大并发一般都是通过异步来完成的
另外go的并发模型也相当简单 其实node可能更简单 但是局限性大一些
如果不是为了并发还选择go的话 我就不是很理解了 除非是以前用了个烂语言
go的异步简单到程序员都感觉不到异步了
【在 l******t 的大作中提到】
: 都是干货啊。
: GO并发怎么好，给个例子？
:
: 是C
: 点。
|
z****e
发帖数: 54598 | 9 vert.x和go的并发处理模型几乎是一样的
都比node复杂，也都比akka简单
看懂了一个，另外一个自然就理解了
【在 l******t 的大作中提到】
: 都是干货啊。
: GO并发怎么好，给个例子？
:
: 是C
: 点。
|
z****e
发帖数: 54598 | 10
node不允许thread存在，这个太消耗性能
web凑合，一个棋牌乐就挂了
【在 p*****2 的大作中提到】
: go 的异步是go来帮你做
: 而其他语言都需要程序员来take care of
: 现在的大并发一般都是通过异步来完成的
: 另外go的并发模型也相当简单 其实node可能更简单 但是局限性大一些
: 如果不是为了并发还选择go的话 我就不是很理解了 除非是以前用了个烂语言
: go的异步简单到程序员都感觉不到异步了
|
|
|
j******f
发帖数: 825 | |
p*****2
发帖数: 21240 | 12 为什么消耗性能
【在 z****e 的大作中提到】
:
: node不允许thread存在，这个太消耗性能
: web凑合，一个棋牌乐就挂了
|
p*****2
发帖数: 21240 | 13 确实类似 不过async不一样
【在 z****e 的大作中提到】
: vert.x和go的并发处理模型几乎是一样的
: 都比node复杂，也都比akka简单
: 看懂了一个，另外一个自然就理解了
|
z****e
发帖数: 54598 | 14 multiple thread -> multiple process
很显然吧？
【在 p*****2 的大作中提到】
: 为什么消耗性能
|
z****e
发帖数: 54598 | 15 实现部分不管了
能用便可
【在 p*****2 的大作中提到】
: 确实类似 不过async不一样
|
p*****2
发帖数: 21240 | 16 这个真不知道没有的话又如何
有了还成go的标准写法了
【在 j******f 的大作中提到】
: 看到那个冒号加等于号我要吐了
|
j******f
发帖数: 825 | 17 多线程的问题也不少吧
【在 z****e 的大作中提到】
: multiple thread -> multiple process
: 很显然吧？
|
z****e
发帖数: 54598 | 18 总比多进程强太多了吧？
多进程共享个资源，都一堆事
而且多开几个就出问题了
【在 j******f 的大作中提到】
: 多线程的问题也不少吧
|
W***o
发帖数: 6519 | 19 SWIFT也一样
【在 j******f 的大作中提到】
: 看到那个冒号加等于号我要吐了
|
x****k
发帖数: 2932 | 20 不是抬杠，回骂就免了，能具体聊聊c++里哪些特性让人吐血吗？
【在 z****e 的大作中提到】
: go,java这些都是用c++的人用吐血后作出的东西
: 可见c++有多糟糕
: 教主都废弃了c++，而选择了obj c
: obj c多冷门的东西，教主情愿用这个，都不愿意选择c++啊
: swift之后就更没c++啥事了，c++一点一点退出历史舞台
|
|
|
l*********s
发帖数: 5409 | 21 go的开发理念太赞了，如果不是go出来的晚，没赶上android，java妥妥的进棺材躺了。 |
z****e
发帖数: 54598 | 22 拉倒吧，人家早就写清楚了，go是用来对付大项目的
android上app算个p大项目
了。
【在 l*********s 的大作中提到】
: go的开发理念太赞了，如果不是go出来的晚，没赶上android，java妥妥的进棺材躺了。
|
z****e
发帖数: 54598 | 23 原文不是写得很清楚了？
你就看go去掉了什么
【在 x****k 的大作中提到】
: 不是抬杠，回骂就免了，能具体聊聊c++里哪些特性让人吐血吗？
|
l*********s
发帖数: 5409 | 24 赵老师语无伦次了啊，java做大项目比不过go 所以小p项目就比go强？
【在 z****e 的大作中提到】
: 拉倒吧，人家早就写清楚了，go是用来对付大项目的
: android上app算个p大项目
:
: 了。
|
l*********s
发帖数: 5409 | 25 这是把工程当艺术了，值得尊敬但是现实是真正的艺术家大多穷困潦倒。所以不是我们
凡人的榜样。
【在 z****e 的大作中提到】
: C++程序员不愿意转向Go是因为他们竭尽全力只为了对自己的程序的完全掌控，并不希
: 望这样改变。对于他们，软件并不仅是完成工作，而是做好工作。
|
z****e
发帖数: 54598 | 26 你到底写过app和go没有？
go那种并发模型根本不适合用来做app
app的ui主线程＋游戏循环双线程模式压根不需要用什么并发模型
总共就那点线程，你并发什么？稍微留意一下，用点原子操作就可以通信了
连lock都是free的，很容易实现
而且app大量使用oop，因为游戏建模用object来映射现实尤为简单
这就是为啥c++在游戏中大量使用的主因，而不是c，就多了oop的部分
go的oop弱的那叫一个不行，apple都用了obj c，obj什么意思？
【在 l*********s 的大作中提到】
: 赵老师语无伦次了啊，java做大项目比不过go 所以小p项目就比go强？
|
z****e
发帖数: 54598 | 27 我写的app里面没有用任何的lock，synchronised关键字，以及java.util.concurrent
包里面的任何一个类
总共就两个线程，跟真正server side的大并发一堆线程涌入是完全两个概念
go和vert.x的模型显然不适合双线程，属于典型的杀鸡用牛刀，不直观不说，而且还很
麻烦
你要介入并发模型，然后把ui thread塞进去，这就改动了本身的实现，p事一堆
还不如不做 |
l*********s
发帖数: 5409 | 28 二爷说的好，oop是c++的糟粕，连c++11都要掉转方向了，java还要在粪坑死撑 Orz。
本来如果要开发android native也只能捏鼻子忍了，反正object-c也很烂，谁想swift
横空出世，从此以后，开发ios antive不仅赚钱多，还是种享受，俺本来想学anroid的
，现在想想还是学swift更加有前途！
【在 z****e 的大作中提到】
: 你到底写过app和go没有？
: go那种并发模型根本不适合用来做app
: app的ui主线程＋游戏循环双线程模式压根不需要用什么并发模型
: 总共就那点线程，你并发什么？稍微留意一下，用点原子操作就可以通信了
: 连lock都是free的，很容易实现
: 而且app大量使用oop，因为游戏建模用object来映射现实尤为简单
: 这就是为啥c++在游戏中大量使用的主因，而不是c，就多了oop的部分
: go的oop弱的那叫一个不行，apple都用了obj c，obj什么意思？
|
z****e
发帖数: 54598 | 29 swift也是oop好不好
app开发根本就是oop的天下
但凡是用来搞app的语言，都无一例外强调oop
c#,obj c,swift,java甚至c++都是oop味道很浓的语言
否则建个p模，一辆坦克你说不用object用啥？
type吗？说白了你就是没写过哪怕一个app
连想都没想过，就知道瞎bb
swift
【在 l*********s 的大作中提到】
: 二爷说的好，oop是c++的糟粕，连c++11都要掉转方向了，java还要在粪坑死撑 Orz。
: 本来如果要开发android native也只能捏鼻子忍了，反正object-c也很烂，谁想swift
: 横空出世，从此以后，开发ios antive不仅赚钱多，还是种享受，俺本来想学anroid的
: ，现在想想还是学swift更加有前途！
|
l*********s
发帖数: 5409 | 30 赵老师说的还是java是android的唯一官方支持/framework这件事，但是就算是android
studio这样滴神器，写出来的code还是吊丝气息太浓厚太缺乏美感了。一个缺乏美感
的开发人员，就算把美工外包了，他的ds气息还是会在细节中暴露出来的。
concurrent
【在 z****e 的大作中提到】
: 我写的app里面没有用任何的lock，synchronised关键字，以及java.util.concurrent
: 包里面的任何一个类
: 总共就两个线程，跟真正server side的大并发一堆线程涌入是完全两个概念
: go和vert.x的模型显然不适合双线程，属于典型的杀鸡用牛刀，不直观不说，而且还很
: 麻烦
: 你要介入并发模型，然后把ui thread塞进去，这就改动了本身的实现，p事一堆
: 还不如不做
|
|
|
z****e
发帖数: 54598 | 31 什么狗屁，你建模时候不用oop，用func吗？
有病嘛这不是，你就是没写过，死撑啥呀
android支持的framework多了，guice都有一个android版
你别丢人了
android
【在 l*********s 的大作中提到】
: 赵老师说的还是java是android的唯一官方支持/framework这件事，但是就算是android
: studio这样滴神器，写出来的code还是吊丝气息太浓厚太缺乏美感了。一个缺乏美感
: 的开发人员，就算把美工外包了，他的ds气息还是会在细节中暴露出来的。
:
: concurrent
|
l*********s
发帖数: 5409 | 32 functional 已经包括了oo，赵老师落伍了。guice不还是java，陈词滥调，赵老师说说
有没有可以用scala,swift开发android native的？
【在 z****e 的大作中提到】
: 什么狗屁，你建模时候不用oop，用func吗？
: 有病嘛这不是，你就是没写过，死撑啥呀
: android支持的framework多了，guice都有一个android版
: 你别丢人了
:
: android
|
z****e
发帖数: 54598 | 33 包括oo并不代表就是oo
你要是在app代码中把程序写成fp或者procedural那样
我靠，那叫一个神经病
我是没听说谁会这样搞的，虽然我知道怎么做
但是建模时候毫不客气都是oop
我也很怀疑其他人会不会这样做，至少我没听说谁这样做过
fp那种搞法，像immutable，用不了多久，你的内存就爆了
就开始gc了，一s就可以让你gc一次，你还玩个p游戏
所以不用想什么scala,clojure这种破烂了，app上没戏
没听说谁用过的，swift就是oop，什么enum这些，你打算论证enum是fp的东西吗？
【在 l*********s 的大作中提到】
: functional 已经包括了oo，赵老师落伍了。guice不还是java，陈词滥调，赵老师说说
: 有没有可以用scala,swift开发android native的？
|
l*********s
发帖数: 5409 | 34 赵老师应该看看fp的内存管理实现，精妙绝伦，堪比gc。如果说java是c++--, 那么fp
就是java--，鼓吹java抵制fp我觉得很是精分！
【在 z****e 的大作中提到】
: 包括oo并不代表就是oo
: 你要是在app代码中把程序写成fp或者procedural那样
: 我靠，那叫一个神经病
: 我是没听说谁会这样搞的，虽然我知道怎么做
: 但是建模时候毫不客气都是oop
: 我也很怀疑其他人会不会这样做，至少我没听说谁这样做过
: fp那种搞法，像immutable，用不了多久，你的内存就爆了
: 就开始gc了，一s就可以让你gc一次，你还玩个p游戏
: 所以不用想什么scala,clojure这种破烂了，app上没戏
: 没听说谁用过的，swift就是oop，什么enum这些，你打算论证enum是fp的东西吗？
|
z****e
发帖数: 54598 | 35 神经病
语言只是工具
工具最重要的是实现目的
而不是装逼
有这功夫去装逼，我app都上线五个版本了
精妙有p用，实现目的是第一要求
建模不顺手，频繁触发gc，这都是app开发的大忌
immutable应该毫不客气干掉，因为游戏中对象的状态变化得很频繁
如果用fp方式建模，很快就会导致内存暴涨，总共就那么点内存
还频繁触发gc，搞啥呀？
而且enum应该毫不客气拿出来用，因为可以杜绝一些错误
这里说的是app，不是general地说其他环境，不要随随便便apply到server上去
明明没做过，也不知道到底是怎么回事，就鼓吹一个自己都不了解的领域
我觉得这才是精分的表现
fp
【在 l*********s 的大作中提到】
: 赵老师应该看看fp的内存管理实现，精妙绝伦，堪比gc。如果说java是c++--, 那么fp
: 就是java--，鼓吹java抵制fp我觉得很是精分！
|
l*********s
发帖数: 5409 | 36 赵老师说的都是马后炮，证明不了你的结论。建模不顺是因为你对fp不熟，android使
用java也是历史遗留问题。
【在 z****e 的大作中提到】
: 神经病
: 语言只是工具
: 工具最重要的是实现目的
: 而不是装逼
: 有这功夫去装逼，我app都上线五个版本了
: 精妙有p用，实现目的是第一要求
: 建模不顺手，频繁触发gc，这都是app开发的大忌
: immutable应该毫不客气干掉，因为游戏中对象的状态变化得很频繁
: 如果用fp方式建模，很快就会导致内存暴涨，总共就那么点内存
: 还频繁触发gc，搞啥呀？
|
z****e
发帖数: 54598 | 37 lol
是不是真的不熟不知道
这个太过于感性，文科生的词汇
但是这一块显然比你熟
【在 l*********s 的大作中提到】
: 赵老师说的都是马后炮，证明不了你的结论。建模不顺是因为你对fp不熟，android使
: 用java也是历史遗留问题。
|
l*********s
发帖数: 5409 | 38 lol，比我熟100倍也没用。学过统计吧，你的个人经验代表群体的平均值的可能无限趋
近于0. :-)
【在 z****e 的大作中提到】
: lol
: 是不是真的不熟不知道
: 这个太过于感性，文科生的词汇
: 但是这一块显然比你熟
|
z****e
发帖数: 54598 | 39 sample size>28的话，很容易就可以推断出population mean的范围了
我想我接触过的app developer超过30个应该问题不大
【在 l*********s 的大作中提到】
: lol，比我熟100倍也没用。学过统计吧，你的个人经验代表群体的平均值的可能无限趋
: 近于0. :-)
|
l*********s
发帖数: 5409 | 40 sampling bias, 赵老师。
【在 z****e 的大作中提到】
: sample size>28的话，很容易就可以推断出population mean的范围了
: 我想我接触过的app developer超过30个应该问题不大
|
|
|
p*****2
发帖数: 21240 | 41 感觉你一直不懂异步
【在 z****e 的大作中提到】
: multiple thread -> multiple process
: 很显然吧？
|
p*****2
发帖数: 21240 | 42 有道理 我想到Android要用java心里就颤
swift确实牛
swift
【在 l*********s 的大作中提到】
: 二爷说的好，oop是c++的糟粕，连c++11都要掉转方向了，java还要在粪坑死撑 Orz。
: 本来如果要开发android native也只能捏鼻子忍了，反正object-c也很烂，谁想swift
: 横空出世，从此以后，开发ios antive不仅赚钱多，还是种享受，俺本来想学anroid的
: ，现在想想还是学swift更加有前途！
|
p*****2
发帖数: 21240 | 43 functional 也有自己的data strucure呀
【在 z****e 的大作中提到】
: 什么狗屁，你建模时候不用oop，用func吗？
: 有病嘛这不是，你就是没写过，死撑啥呀
: android支持的framework多了，guice都有一个android版
: 你别丢人了
:
: android
|
z****e
发帖数: 54598 | 44 immutable
【在 p*****2 的大作中提到】
: functional 也有自己的data strucure呀
|
z****e
发帖数: 54598 | 45 这叫picky
我的bias肯定比你的小，小多了
至少现实也支撑了我的观点
【在 l*********s 的大作中提到】
: sampling bias, 赵老师。
|
z****e
发帖数: 54598 | 46 至少我没把vert.x用失败
【在 p*****2 的大作中提到】
: 感觉你一直不懂异步
|
p*****2
发帖数: 21240 | 47 没有哪个语言是必须immutable的
都可以mutate 只是限制你不要乱用而已
就跟oo的继承一样 有了还不如没有
【在 z****e 的大作中提到】
: immutable
|
p*****2
发帖数: 21240 | 48 vertx不是纯异步
如果你并发量不大的话 确实问题不大
我用node去support 100k tps 这个量就可以了 node基本是纯异步的
【在 z****e 的大作中提到】
: 至少我没把vert.x用失败
|
z****e
发帖数: 54598 | 49 by default就是immutable
如果你要改成mutable的话
挨个改过去
要多傻有多傻了
干脆一开始就不要用
【在 p*****2 的大作中提到】
: 没有哪个语言是必须immutable的
: 都可以mutate 只是限制你不要乱用而已
: 就跟oo的继承一样 有了还不如没有
|
z****e
发帖数: 54598 | 50
那这个真的是开发人员的问题了
看来不是我不懂异步
【在 p*****2 的大作中提到】
: vertx不是纯异步
: 如果你并发量不大的话 确实问题不大
: 我用node去support 100k tps 这个量就可以了 node基本是纯异步的
|
|
|
p*****2
发帖数: 21240 | 51 其实fp
习惯了以后
绝大多数的情况确实不需要mutation
不过fp的优势确实是数据处理 比如spark
也不是万能的
对于并发来说immutability感觉优势也不是特别明显 比如node完全不用担心mutation
go通过chan的model也间接的immutability了 但go不是fp
vertx也类似
【在 z****e 的大作中提到】
: by default就是immutable
: 如果你要改成mutable的话
: 挨个改过去
: 要多傻有多傻了
: 干脆一开始就不要用
|
p*****2
发帖数: 21240 | 52 vertx限制在了jvm了
不过vertx我还没真正搞过 我觉得是我们的dev用的不太好 我觉得比akka要简单易用
当然可能没有akka成熟 毕竟新马
【在 z****e 的大作中提到】
:
: 那这个真的是开发人员的问题了
: 看来不是我不懂异步
|
