c******o
发帖数: 1277 | 1 用了几个月scala. 说一下我的感觉
scala是一个general purpose language, 它有足够的工具解决绝大部分项目和问题。
scala不是一个all purpose language,它明显在很多领域只是可以用而已。大部分领域
有更好的语言了。
我的感觉是，scala最适用于：
1. 多并发，大规模的后端，很好的支持并发。
2. 分布式系统，高可用性，高容错，分布式实现容易。
3. 复杂逻辑后端，有很多很好的抽象方法可以选用，用的好，可以很干净。
4. 各种专业的库，是一个很好的建库的语言，当然，要求也高。
这些主要是因为：
1. FP和OO的融合使得scala有很强大的标准库支持，也很容易使人迷惑， 看看那个
play的Json library, 很强大，也很囧。
2. FP和OO的融合使得scala有很多种抽象的方法，很强大，但是也很容易被滥用，太多
pattern可以用来干同一件事。
3. 静态类型和type inference使得scala很适合大型，复杂的系统,高效的系统，也能
够写出比较简洁和干净的代码，要是不注意，容易影响可读性。
4. 调用java大部分很容易，java调回来就不容易了。。 和JVM联系紧很重要的，不然F
# 也很不错。
我觉得即使你不用scala,也应该在新的multi-paradigm语言(F#,scala,ruby,python
etc.)中选一个学学（scala还是最全的)。一个不变的趋势是越来越多的新特性融入到
新的语言里，scala/F#是一个比较好的地方去了解哪些特性。
比如：
1. mixin/trait
2. type inference with static type
3. first class function, currying
4. Pattern matching, Extractors
5. immutable data structure, map/flatMap/fold combinator etc.
7. implicit conversion for static type
6. lazy value, reference by name
7. Type parameters/generics/variance
8. Higher-kinded types
9. delimited continuation
10. parallel library
11. actor model, event driven model for async IO
10. 如果你真的有毅力,有决心。。 monoid/functor/applicative/monad,
composability |
m******t
发帖数: 635 | 2 怎么感觉你在描述C++， :)
【在 c******o 的大作中提到】
: 用了几个月scala. 说一下我的感觉
: scala是一个general purpose language, 它有足够的工具解决绝大部分项目和问题。
: scala不是一个all purpose language,它明显在很多领域只是可以用而已。大部分领域
: 有更好的语言了。
: 我的感觉是，scala最适用于：
: 1. 多并发，大规模的后端，很好的支持并发。
: 2. 分布式系统，高可用性，高容错，分布式实现容易。
: 3. 复杂逻辑后端，有很多很好的抽象方法可以选用，用的好，可以很干净。
: 4. 各种专业的库，是一个很好的建库的语言，当然，要求也高。
: 这些主要是因为：
|
p*****2
发帖数: 21240 | 3 大牛先说说到底有哪些公司在用AKKA呢？
我怎么看了半天也没找到呢？
用Scala的倒是越来越多，但是我怀疑是不是很多就是拿它当Java用呢。 |
p*****2
发帖数: 21240 | 4
我学过的最难的语言就是VC和Scala了。
【在 m******t 的大作中提到】
: 怎么感觉你在描述C++， :)
|
c******o
发帖数: 1277 | 5 c++并发不是专长吧？
【在 m******t 的大作中提到】
: 怎么感觉你在描述C++， :)
|
m******t
发帖数: 635 | 6 开发用clojure的话，你用什么editor? 你的ClojureScript开发环境能介绍下么？
我年初的时候学了下Clojure，后来半年弄iOS app去了，现在想把Clojure和
ClojureScript从新拣起来，不知道现在流行的开发配置是怎样的。我那个时候是IDEA
J + La Clojure plugin
开发ClojureScript是看的ClojureScript Up and Running这本书。
【在 p*****2 的大作中提到】
:
: 我学过的最难的语言就是VC和Scala了。
|
m*******l
发帖数: 12782 | 7 C++ 11现在加了STL thread, asyc 等等
【在 c******o 的大作中提到】
: c++并发不是专长吧？
|
c******o
发帖数: 1277 | 8 据Martin说有些银行开始用了，但是不让宣扬。
要是不成，大概就要痿了。
本身就是大公司用才爽，小公司用起来有种屠龙的感觉，可以用，也好用，省时间，就
是好像也可以不用，尤其是你本身就用FP，immutability，future。
【在 p*****2 的大作中提到】
: 大牛先说说到底有哪些公司在用AKKA呢？
: 我怎么看了半天也没找到呢？
: 用Scala的倒是越来越多，但是我怀疑是不是很多就是拿它当Java用呢。
|
c******o
发帖数: 1277 | 9 哦，所以兼听则明么。
scala的FP/immutability/future 的async的用法是很不一样的。
看看很好。
【在 m*******l 的大作中提到】
: C++ 11现在加了STL thread, asyc 等等
|
m******t
发帖数: 635 | 10 开玩笑的，我是针对multi-paradigm这条来的, C++可以Procedural, Object-based,
Object-oriented, generic programming (STL)， Scala这是FP + OOP。当然C++和
Scala都是很复杂的语言。
F#好像是最类似于Scala的了: F＃是ML for .Net和 Scala是ML for JVM (再加点
Haskell)。几年前折腾过F#，很容易四不像。如果没有风险投资在后面推的话，Scala
估计就是F#的路子，过一两年就散了。
【在 c******o 的大作中提到】
: c++并发不是专长吧？
|
|
|
p*****2
发帖数: 21240 | 11
IDEA
我没用Clojurescript，还是用coffeescript。
Clojure就用eclipse。还没好好研究IDE。版上的大牛不是很推崇emacs吗？说写
Clojure code超快。
【在 m******t 的大作中提到】
: 开发用clojure的话，你用什么editor? 你的ClojureScript开发环境能介绍下么？
: 我年初的时候学了下Clojure，后来半年弄iOS app去了，现在想把Clojure和
: ClojureScript从新拣起来，不知道现在流行的开发配置是怎样的。我那个时候是IDEA
: J + La Clojure plugin
: 开发ClojureScript是看的ClojureScript Up and Running这本书。
|
g*****g
发帖数: 34805 | 12 说得不错，不过我不同意3。逻辑越复杂的后端，越需要多人合作，容易调试，以及用
SOA来划分以减低复杂度。SOA下用Scala写特定服务未尝不可，全盘Scala，人走了接盘
难度很大。
根本上我持这个观点，越复杂越门槛高的语言，越不适合多人合作和长期维护。
【在 c******o 的大作中提到】
: 用了几个月scala. 说一下我的感觉
: scala是一个general purpose language, 它有足够的工具解决绝大部分项目和问题。
: scala不是一个all purpose language,它明显在很多领域只是可以用而已。大部分领域
: 有更好的语言了。
: 我的感觉是，scala最适用于：
: 1. 多并发，大规模的后端，很好的支持并发。
: 2. 分布式系统，高可用性，高容错，分布式实现容易。
: 3. 复杂逻辑后端，有很多很好的抽象方法可以选用，用的好，可以很干净。
: 4. 各种专业的库，是一个很好的建库的语言，当然，要求也高。
: 这些主要是因为：
|
c******o
发帖数: 1277 | 13 最后还是看是不是有人能做。
说实话，习惯了FP, 回头看看，OO的pattern也不是什么容易的东西（都是理解容易，
用好难）。
主要是要有common practice 来遵守。
【在 g*****g 的大作中提到】
: 说得不错，不过我不同意3。逻辑越复杂的后端，越需要多人合作，容易调试，以及用
: SOA来划分以减低复杂度。SOA下用Scala写特定服务未尝不可，全盘Scala，人走了接盘
: 难度很大。
: 根本上我持这个观点，越复杂越门槛高的语言，越不适合多人合作和长期维护。
|
n*w
发帖数: 3393 | 14 curiously, anyone has used higher order type?
【在 c******o 的大作中提到】
: 用了几个月scala. 说一下我的感觉
: scala是一个general purpose language, 它有足够的工具解决绝大部分项目和问题。
: scala不是一个all purpose language,它明显在很多领域只是可以用而已。大部分领域
: 有更好的语言了。
: 我的感觉是，scala最适用于：
: 1. 多并发，大规模的后端，很好的支持并发。
: 2. 分布式系统，高可用性，高容错，分布式实现容易。
: 3. 复杂逻辑后端，有很多很好的抽象方法可以选用，用的好，可以很干净。
: 4. 各种专业的库，是一个很好的建库的语言，当然，要求也高。
: 这些主要是因为：
|
c******o
发帖数: 1277 | 15 library里到处都是。但是application developer 基本不用。
【在 n*w 的大作中提到】
: curiously, anyone has used higher order type?
|
g*****g
发帖数: 34805 | 16 I think common practice is easier said than done, unless it's enforced by
compiler, particularly with Scala with which common practice is not well
established. And it also gets harder with bigger team and higher turnover
rate. Again my proposition.
Going back to OO. OO is not necessarily easy, but probably map to human's
comprehension to the physical world best among current programming paradigms.
【在 c******o 的大作中提到】
: 最后还是看是不是有人能做。
: 说实话，习惯了FP, 回头看看，OO的pattern也不是什么容易的东西（都是理解容易，
: 用好难）。
: 主要是要有common practice 来遵守。
|
z****e
发帖数: 54598 | 17 你不能指望别人iq高到一定程度才来接盘
这个接盘接多了，人家也会很烦的
我就是从毕业开始不停滴去接盘，每次接盘
心里都把上一任的祖宗给操了个遍
而且这个东西也不是毫无代价的
时间久了，我也会要求涨工资，这种烂摊子没有几个人真爱接的
接盘的人一涨工资，其实就是你们乱写代码还回去的时候
我们搞软件工程出身的，对于这种项目维护成本上涨是非常敏感的
这基本上是要挂的节奏
【在 c******o 的大作中提到】
: 最后还是看是不是有人能做。
: 说实话，习惯了FP, 回头看看，OO的pattern也不是什么容易的东西（都是理解容易，
: 用好难）。
: 主要是要有common practice 来遵守。
|
z****e
发帖数: 54598 | 18 真正合理的multi-paradigm应该是要用的时候，通过一个插件或者类库来扩展
不要用的时候，不让你用，而不是让你可用可不用的选择
java这点做得很好，你想aop，那就必需弄aspect j才能用
不装就不让你用，因为程序猿习惯于装逼
它写了，往往不在乎别人的感受，只要它有装逼的空间，它就会去装
现在的工具总是尝试着做得又大又全，什么都提供
那些看上去很fancy的feature，只要有机会它就会去用，而且散落在代码的各个角落
debug都debug不出来，这是接盘时候最头疼的问题
clojure在fp上其实做得比scala好，就在于clojure它介入java空间相对少
不影响oo基础之上，你要用clojure，你得额外安装lib，而不是像scala一样
把两种不同的paradigm凑在一起，凑在一起的结果就是两不象，最后fp的人不喜欢
oo的人也不喜欢，因为喜欢oo的程序猿会讨厌代码里面fp的部分
反过来也一样，代码的耦合性增强了，大幅降低了可读性，不错我觉得clojure做得还
不够好
你看aop的aspect j对一般java的侵入就较少，几乎是强制要求aop的代码和oo代码分离
当然最后class还是会变成同一个东西，但是一般程序猿管不了class，那是jvm的事
这样就很容易找到两个不同风格的程序猿，让它们合作
说到底都是合作的问题，真想multi-paradigm？
先去看看什么是aop再说，aop也是paradigm的一种，不是只有fp才是
aop还是一个比较成功的例子 |
s***o
发帖数: 2191 | 19 好帖要顶。
你觉着你们会继续大规模使用Scala，还是会慢慢fall back to Java？
【在 c******o 的大作中提到】
: 用了几个月scala. 说一下我的感觉
: scala是一个general purpose language, 它有足够的工具解决绝大部分项目和问题。
: scala不是一个all purpose language,它明显在很多领域只是可以用而已。大部分领域
: 有更好的语言了。
: 我的感觉是，scala最适用于：
: 1. 多并发，大规模的后端，很好的支持并发。
: 2. 分布式系统，高可用性，高容错，分布式实现容易。
: 3. 复杂逻辑后端，有很多很好的抽象方法可以选用，用的好，可以很干净。
: 4. 各种专业的库，是一个很好的建库的语言，当然，要求也高。
: 这些主要是因为：
|
z****e
发帖数: 54598 | 20 我们研究一个东西的方向，应该从成功的案例中汲取经验
而不是上来就做上帝，那谁受得了，你丫的制定的规则别两三年之后你自己都不遵守
那谁能接受这种改变，变来变去的东西最讨厌了
做过项目的都知道，需求是最难搞定的，变来变去的客户需求最烦
但是需求可能没有办法，因为现实复杂性，但是编程paradigm这种
那还是有大量经验教训可以汲取的
应该从成功的产品，比如aspect j, spring这种产品中汲取营养
而不是把一个东西往ejb那个方向去做
ejb垃圾么？很多人这么认为，其实ejb也不难，无非要求你搞点xml而已
问题在于，spring太简单了，看到这个区别了没有？
在现有基础之上，谁能不需要培训就上手，谁就能胜出
ejb和五笔一样，倒腾半天，五笔还更变态，还要背，尼玛
我相信这里大多数人打字用的其实还是拼音，而不是五笔
一句话总结：让所有的装逼犯都去死吧 |
|
|
z****e
发帖数: 54598 | 21 java常用的reflection其实也是一种paradigm
Metaprogramming，元数据编程
话说谈multi-paradigm，java本身就是一个很好的例子
reflection本身还是很tricky的，不提倡初学者去用
但是如果spring这种，没有reflection，那基本上做不出来
还有工作流，也是一种paradigm，多数时候是event-driven
这些都是比较成功的领域 |
c******o
发帖数: 1277 | 22 现在肯定还是继用啊
【在 s***o 的大作中提到】
: 好帖要顶。
: 你觉着你们会继续大规模使用Scala，还是会慢慢fall back to Java？
|
x****u
发帖数: 44466 | 23 这样并发就更不是专长了。
CPP11的特性是鼓励新手程序员生产垃圾的。
【在 m*******l 的大作中提到】
: C++ 11现在加了STL thread, asyc 等等
|
n*w
发帖数: 3393 | 24 哪里有higher order type和非higher order type一个实现比较？想学习一下。google
了一下，没找到。可能是因为支持higher order type的语言太少？
【在 c******o 的大作中提到】
: library里到处都是。但是application developer 基本不用。
|
c*******n
发帖数: 2764 | 25 学了两周，东西太花哨了，果断放弃
【在 c******o 的大作中提到】
: 用了几个月scala. 说一下我的感觉
: scala是一个general purpose language, 它有足够的工具解决绝大部分项目和问题。
: scala不是一个all purpose language,它明显在很多领域只是可以用而已。大部分领域
: 有更好的语言了。
: 我的感觉是，scala最适用于：
: 1. 多并发，大规模的后端，很好的支持并发。
: 2. 分布式系统，高可用性，高容错，分布式实现容易。
: 3. 复杂逻辑后端，有很多很好的抽象方法可以选用，用的好，可以很干净。
: 4. 各种专业的库，是一个很好的建库的语言，当然，要求也高。
: 这些主要是因为：
|
c*******9
发帖数: 9032 | 26 真正复杂的逻辑是难分割的。
【在 g*****g 的大作中提到】
: 说得不错，不过我不同意3。逻辑越复杂的后端，越需要多人合作，容易调试，以及用
: SOA来划分以减低复杂度。SOA下用Scala写特定服务未尝不可，全盘Scala，人走了接盘
: 难度很大。
: 根本上我持这个观点，越复杂越门槛高的语言，越不适合多人合作和长期维护。
|
q*c
发帖数: 9453 | 27 那种地方就该一个人搞定。
世界上哪里有那么多真正复杂的东西， 我们这种幼稚的文明还用不到。
什么时候到了银河时代再谈每个人都需要搞定真正复杂的东西。
【在 c*******9 的大作中提到】
: 真正复杂的逻辑是难分割的。
|
H****S
发帖数: 1359 | 28 用spray做rest server的就等于是在用akka啊。spray can的benchmark比netty还要好
，code可读性又好很多。你可以看看现在有多少project在用netty
【在 c******o 的大作中提到】
: 据Martin说有些银行开始用了，但是不让宣扬。
: 要是不成，大概就要痿了。
: 本身就是大公司用才爽，小公司用起来有种屠龙的感觉，可以用，也好用，省时间，就
: 是好像也可以不用，尤其是你本身就用FP，immutability，future。
|
c******o
发帖数: 1277 | 29 大部分需求其实future/workflow就解决了，
真的必须用到agent/actor的不多，再说用actor的话实在在算法和思维上都很有挑战性
，必须从distribute, async, decoupling来考虑，做起来其实不容易。
要是没需要，还是简单的好。
【在 H****S 的大作中提到】
: 用spray做rest server的就等于是在用akka啊。spray can的benchmark比netty还要好
: ，code可读性又好很多。你可以看看现在有多少project在用netty
|
H****S
发帖数: 1359 | 30 actor是reacting programming的corner stone，这个对于web server design基本就有
天生的优势。它和future的关系实质因该是互补的。我也不觉得actor有什么难的，难
得反而是避免abuse actor，比如很多人先入为主会从线程的角度来理解actor，写出的
code也可象而至是怎样。
【在 c******o 的大作中提到】
: 大部分需求其实future/workflow就解决了，
: 真的必须用到agent/actor的不多，再说用actor的话实在在算法和思维上都很有挑战性
: ，必须从distribute, async, decoupling来考虑，做起来其实不容易。
: 要是没需要，还是简单的好。
|
|
|
c******o
发帖数: 1277 | 31 我觉得 async才是吧？
node也被称为reactive,根本不是actor.
说它不容易和从线程关系不那么大。
actor的location neutrual 在distributed system根本就和和单机上写相同逻辑两种
概念。难很多。
【在 H****S 的大作中提到】
: actor是reacting programming的corner stone，这个对于web server design基本就有
: 天生的优势。它和future的关系实质因该是互补的。我也不觉得actor有什么难的，难
: 得反而是避免abuse actor，比如很多人先入为主会从线程的角度来理解actor，写出的
: code也可象而至是怎样。
|
