由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - go几天的一些感受
相关主题
我还是认为scala的程序员水平高functional programming?
swift不是fp语言学FP不是为了写代码, 而是为了优秀的架构.
java 8就是一坨屎模板算是纯FP吗
Java EE这东西还有必要学吗有没有喜欢haskell的同学
阅读scala中对 (im)mutability 的误解和深度理解
谁能推荐个好的编程语言?王垠新文 为Java说句公道话
Haskell很难学。。Duck typing is great ...
粉FP的人是因为把电脑想象成图灵机了看了一下C#的async await
相关话题的讨论汇总
话题: go话题: java话题: c++话题: 并发话题: oop
进入Programming版参与讨论
1 (共1页)
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的异步简单到程序员都感觉不到异步了

相关主题
谁能推荐个好的编程语言?functional programming?
Haskell很难学。。学FP不是为了写代码, 而是为了优秀的架构.
粉FP的人是因为把电脑想象成图灵机了模板算是纯FP吗
进入Programming版参与讨论
j******f
发帖数: 825
11
看到那个冒号加等于号我要吐了
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++一点一点退出历史舞台

相关主题
有没有喜欢haskell的同学Duck typing is great ...
对 (im)mutability 的误解和深度理解看了一下C#的async await
王垠新文 为Java说句公道话go is ugly
进入Programming版参与讨论
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事一堆
: 还不如不做

相关主题
面向数据的编程与面向对象的编程swift不是fp语言
FP over head很高java 8就是一坨屎
我还是认为scala的程序员水平高Java EE这东西还有必要学吗
进入Programming版参与讨论
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个应该问题不大

相关主题
Java EE这东西还有必要学吗Haskell很难学。。
阅读scala中粉FP的人是因为把电脑想象成图灵机了
谁能推荐个好的编程语言?functional programming?
进入Programming版参与讨论
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基本是纯异步的

相关主题
学FP不是为了写代码, 而是为了优秀的架构.对 (im)mutability 的误解和深度理解
模板算是纯FP吗王垠新文 为Java说句公道话
有没有喜欢haskell的同学Duck typing is great ...
进入Programming版参与讨论
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 的大作中提到】
:
: 那这个真的是开发人员的问题了
: 看来不是我不懂异步

1 (共1页)
进入Programming版参与讨论
相关主题
看了一下C#的async await阅读scala中
go is ugly谁能推荐个好的编程语言?
面向数据的编程与面向对象的编程Haskell很难学。。
FP over head很高粉FP的人是因为把电脑想象成图灵机了
我还是认为scala的程序员水平高functional programming?
swift不是fp语言学FP不是为了写代码, 而是为了优秀的架构.
java 8就是一坨屎模板算是纯FP吗
Java EE这东西还有必要学吗有没有喜欢haskell的同学
相关话题的讨论汇总
话题: go话题: java话题: c++话题: 并发话题: oop