p*****2
发帖数: 21240 | 1 我的感觉不比coffee差 甚至还要强 当然问题是很不容易精通
coffee毕竟还是javascript， 设计并不完备， 做复杂程序劣势就出来了
不过我最近研究了一下startups 貌似用scala的好的startup不多呀 还是python这种要
广泛很多 要不就是node |
h*******3
发帖数: 122 | 2 startup能找到那么多scala人才不
【在 p*****2 的大作中提到】
: 我的感觉不比coffee差 甚至还要强 当然问题是很不容易精通
: coffee毕竟还是javascript， 设计并不完备， 做复杂程序劣势就出来了
: 不过我最近研究了一下startups 貌似用scala的好的startup不多呀 还是python这种要
: 广泛很多 要不就是node
|
r***y
发帖数: 4379 | 3 大牛, maintainability 咋样呀?
自己写过的代码一年两年后看还爽吗? 还是第一次爽完就拉倒?
【在 p*****2 的大作中提到】
: 我的感觉不比coffee差 甚至还要强 当然问题是很不容易精通
: coffee毕竟还是javascript， 设计并不完备， 做复杂程序劣势就出来了
: 不过我最近研究了一下startups 貌似用scala的好的startup不多呀 还是python这种要
: 广泛很多 要不就是node
|
l*******b
发帖数: 2586 | 4 python 写复杂了看起来一样头痛呀, 尤其inheritance里各种override各种call。
functional肯定比oop好scale, oop想完全封装一个东西也很难, 但是速度上快, 出
code也快
关键还是看写的时候有没有规划好怎么添加模块, 怎么改进。和啥语言关系真不大。
【在 r***y 的大作中提到】
: 大牛, maintainability 咋样呀?
: 自己写过的代码一年两年后看还爽吗? 还是第一次爽完就拉倒?
|
z****e
发帖数: 54598 | 5 oop完全封装一个东西难？
你不封装只能用反射，你觉得反射很容易写？
java最大的好处就在于，你不oop的话，有门槛和编码成本
一般小p孩跨越不过去，所以老老实实oop
python最大的问题就在于，一般小p孩，一偷懒，就不oop了
导致垃圾满天飞，鬼知道他在写啥，到最后大量时间投入在给p孩擦屁股上
只要每个人都那么无私，共产主义就实现了呀
【在 l*******b 的大作中提到】
: python 写复杂了看起来一样头痛呀, 尤其inheritance里各种override各种call。
: functional肯定比oop好scale, oop想完全封装一个东西也很难, 但是速度上快, 出
: code也快
: 关键还是看写的时候有没有规划好怎么添加模块, 怎么改进。和啥语言关系真不大。
|
p*****2
发帖数: 21240 | 6 目前感觉问题不大 前提是对fp比较熟 而且写code不要乱来 至于什么算乱来 还需要进
一步体会
【在 r***y 的大作中提到】
: 大牛, maintainability 咋样呀?
: 自己写过的代码一年两年后看还爽吗? 还是第一次爽完就拉倒?
|
r***y
发帖数: 4379 | 7 真的就象楼上老赵说的.
用过的语言中... 个人感觉 Java 是最适合团队作业... 可以把小p孩也规矩的不范大
毛病... 那种靠规章制度的规范真操作起来很扯的...
【在 l*******b 的大作中提到】
: python 写复杂了看起来一样头痛呀, 尤其inheritance里各种override各种call。
: functional肯定比oop好scale, oop想完全封装一个东西也很难, 但是速度上快, 出
: code也快
: 关键还是看写的时候有没有规划好怎么添加模块, 怎么改进。和啥语言关系真不大。
|
r***y
发帖数: 4379 | 8 谢谢大牛分享.
"写code不要乱来" 这点看来, 不太适合大团队作业啊... 人一多了可什么鸟都有呀...
或者说, 大团队作业时候, 定规矩执行规矩的成本会比较高...
【在 p*****2 的大作中提到】
: 目前感觉问题不大 前提是对fp比较熟 而且写code不要乱来 至于什么算乱来 还需要进
: 一步体会
|
p*****2
发帖数: 21240 | 9 这个我不反对
说实话 大团队的话 我i还真怀疑是不是每个人都愿意并且能把scala学好
我在大团队工作时间太久了 现在喜欢在小团队
总之每种语言都有各自的优势 分情况使用 多学几种就多些选择 而且能相互对照 互相
理解 很有意思
..
【在 r***y 的大作中提到】
: 谢谢大牛分享.
: "写code不要乱来" 这点看来, 不太适合大团队作业啊... 人一多了可什么鸟都有呀...
: 或者说, 大团队作业时候, 定规矩执行规矩的成本会比较高...
|
l*******b
发帖数: 2586 | 10 难, 状态太多, maintain不过来, 一个函数好多好多参数。又想有随时修改的自由, 又
想默认的就好用。
东西越往一起凑要maintain的状态越多, 然候就悲剧了
【在 z****e 的大作中提到】
: oop完全封装一个东西难？
: 你不封装只能用反射，你觉得反射很容易写？
: java最大的好处就在于，你不oop的话，有门槛和编码成本
: 一般小p孩跨越不过去，所以老老实实oop
: python最大的问题就在于，一般小p孩，一偷懒，就不oop了
: 导致垃圾满天飞，鬼知道他在写啥，到最后大量时间投入在给p孩擦屁股上
: 只要每个人都那么无私，共产主义就实现了呀
|
|
|
z****e
发帖数: 54598 | 11 那要看什么样的公式
bm25那种是有点多，不过也没有超过6个
而且分子和分母一做分解之后，就少更多了
但是这是很高大上的东西
一般写web用脚本的公司，你跟我说函数会有好多好多参数？
会有很复杂的数学计算？
我不信
而且一个最简单的设计pattern就是把你这些好多好多参数
包装成一个大的dto，这样就可以轻松定义default value鸟
【在 l*******b 的大作中提到】
: 难, 状态太多, maintain不过来, 一个函数好多好多参数。又想有随时修改的自由, 又
: 想默认的就好用。
: 东西越往一起凑要maintain的状态越多, 然候就悲剧了
|
l*******b
发帖数: 2586 | 12 整点统计的, 一个模型各种参数, 各种输入接口。包装是一定的, call别人的库必须
unpack, 一家和另一家结构都不一样。
【在 z****e 的大作中提到】
: 那要看什么样的公式
: bm25那种是有点多，不过也没有超过6个
: 而且分子和分母一做分解之后，就少更多了
: 但是这是很高大上的东西
: 一般写web用脚本的公司，你跟我说函数会有好多好多参数？
: 会有很复杂的数学计算？
: 我不信
: 而且一个最简单的设计pattern就是把你这些好多好多参数
: 包装成一个大的dto，这样就可以轻松定义default value鸟
|
w***g
发帖数: 5958 | 13 我可能是在找骂。我的理解是一个startup的产品是需要很多iteration的。按那钱时间
分的话是
1. 拿angel fund之前：出一个糙快猛的demo，但是没有什么会最终保留到产品里。这
个阶段发挥作用的主要是founder，并不需要很好的代码质量。每个人拿的equity可能>
10%，没有工资。
2. 拿series A之前：有确定的磁盘数据结构(sql schema)和模块间的接口。最核心的
那些代码可能基本上finalize了，但是外围由很多还是糙快猛的东西。这个阶段需要一
两个技术大拿来确定基本框架，加起来可能有三五个全栈程序员以一当十把东西做出来
。这个阶段加入的人equity最多也就1~2%，一般可能也就0.x%。这时候加入的那些人基
本上确定了整个公司的culture，这些人几年之内不应该离职。
3. 拿到series A之后由足够的人力了，再精打细造各个模块和增加更多的模块。这时
候再加入，除非公司IPO或者卖大钱，equity实际上已经没太大意义了。这时候单个员
工做的东西和公司的生死存亡其实已经没太大关系了。
2之前最重要的是设计/架构而不是编码，2之后才是大量的编码，而且代码量是指数增
长的。
把2之前的东西重新写一遍根本不在话下。因为这段时间对公司业务和用户的理解可能
有大量更新，所以很多东西是不得不重写的。
Scala糙快猛的这一面主要是在1和2这个阶段发挥作用。3以后software engineering才
开始kick in，写得东西才要保证可维护性。我可能水平不高，也没啥机会，但我对自
己的定位是2这块。我关心的是系统架构/数据结构的稳定性和可扩展性，如何用最少量
的代码写出正确高效运行的系统。只要架构是稳定的，模块内部代码怎么重写其实都不
会伤筋动骨。作为反例，我见过某公司刚把一个核心表的主键从int32改成int64，然后
又要把另一个表的主键从string改成int64，这些改动虽小，但都表明一开始的设计不
好，这样的改动对整个系统可能会产生毁灭性的后果。
话虽如此，我其实看过很多三流程序员写得代码，大量的copy& paste，大量复杂的逻
辑。我觉得我写的代码即使不加文档都比那些更容易维护。
【在 h*******3 的大作中提到】
: startup能找到那么多scala人才不
|
z****e
发帖数: 54598 | 14 随便做个adapater就可以了
然后把adapter单独放一层
你还是缺乏最基本的分层思想
把所有代码凑一起，这个repo会越来越大
几年之后，所有人都在海洋里面游泳
谁也不知道会遇到什么
【在 l*******b 的大作中提到】
: 整点统计的, 一个模型各种参数, 各种输入接口。包装是一定的, call别人的库必须
: unpack, 一家和另一家结构都不一样。
|
z****e
发帖数: 54598 | 15 startup成功与否跟技术其实没啥必然联系
能>
【在 w***g 的大作中提到】
: 我可能是在找骂。我的理解是一个startup的产品是需要很多iteration的。按那钱时间
: 分的话是
: 1. 拿angel fund之前：出一个糙快猛的demo，但是没有什么会最终保留到产品里。这
: 个阶段发挥作用的主要是founder，并不需要很好的代码质量。每个人拿的equity可能>
: 10%，没有工资。
: 2. 拿series A之前：有确定的磁盘数据结构(sql schema)和模块间的接口。最核心的
: 那些代码可能基本上finalize了，但是外围由很多还是糙快猛的东西。这个阶段需要一
: 两个技术大拿来确定基本框架，加起来可能有三五个全栈程序员以一当十把东西做出来
: 。这个阶段加入的人equity最多也就1~2%，一般可能也就0.x%。这时候加入的那些人基
: 本上确定了整个公司的culture，这些人几年之内不应该离职。
|
w***g
发帖数: 5958 | 16 基本上是这样，但是开始的架构如果设计好了能让公司的发展少走很多弯路。
小公司其实没几次推倒重来的机会的，基本上是一招不慎满盘皆输。大公司
有cash cow才可以随便尝试新产品。Business是大前提，但是对互联网公司
来说，技术是一个必要条件。
【在 z****e 的大作中提到】
: startup成功与否跟技术其实没啥必然联系
:
: 能>
|
z****e
发帖数: 54598 | 17 天天把架构挂嘴边的就是最早那些j2ee程序员，你还是经验太少了
所谓架构其实就是软件工程这个行当炒作出来的一个buzz word
以前ibm一开seminar，言必称架构
其实架构要理解也很容易，分层分清楚了
要想失败，好像也很难，提倡糙快猛的往往缺乏层次这个概念
最后会不得不重构，所以糙快猛和架构也就是不需要推倒重来恰恰是有些冲突的
【在 w***g 的大作中提到】
: 基本上是这样，但是开始的架构如果设计好了能让公司的发展少走很多弯路。
: 小公司其实没几次推倒重来的机会的，基本上是一招不慎满盘皆输。大公司
: 有cash cow才可以随便尝试新产品。Business是大前提，但是对互联网公司
: 来说，技术是一个必要条件。
|
w***g
发帖数: 5958 | 18 出了三层架构或者MVC这个框框，要把分层分清楚是很难的事情。
我这两天在做实时推荐，哪些数据要存硬盘，哪些数据要常驻内存，
哪些要cache，哪些要redundant，哪些丢了也不怕，哪儿可能是
I/O瓶颈，哪些性能无所谓，这些都要想明白，然后再选用最合适
的软件。我觉得我的经验比你们大部分人都多多了。
我见到的大部分人设计数据结构都是在选定了软件之后进行的。
你说的j2ee程序员，对于很多人来说lucene都是一个新东西，能有多少经验。
【在 z****e 的大作中提到】
: 天天把架构挂嘴边的就是最早那些j2ee程序员，你还是经验太少了
: 所谓架构其实就是软件工程这个行当炒作出来的一个buzz word
: 以前ibm一开seminar，言必称架构
: 其实架构要理解也很容易，分层分清楚了
: 要想失败，好像也很难，提倡糙快猛的往往缺乏层次这个概念
: 最后会不得不重构，所以糙快猛和架构也就是不需要推倒重来恰恰是有些冲突的
|
d******e
发帖数: 2265 | 19 scala最后一定会比java 程序好懂。因为笨蛋程序员，裱糊匠程序员都进不了这个门槛。
【在 p*****2 的大作中提到】
: 目前感觉问题不大 前提是对fp比较熟 而且写code不要乱来 至于什么算乱来 还需要进
: 一步体会
|
d******e
发帖数: 2265 | 20 大团队就是扯淡。
【在 p*****2 的大作中提到】
: 这个我不反对
: 说实话 大团队的话 我i还真怀疑是不是每个人都愿意并且能把scala学好
: 我在大团队工作时间太久了 现在喜欢在小团队
: 总之每种语言都有各自的优势 分情况使用 多学几种就多些选择 而且能相互对照 互相
: 理解 很有意思
:
: ..
|
|
|
z****e
发帖数: 54598 | 21 我觉得架构层次没啥特别难懂的
三层不够就分成4－5层，一样的嘛
persistence你按照cap分成三类，然后根据structure程度再分三类
这里就有9类了，已经很细了，足够用了
然后我觉得structure程度越高，越没啥可以搞的
越低，越有搞头，对于数学的需求就越高
创业发财的机会也就越多
【在 w***g 的大作中提到】
: 出了三层架构或者MVC这个框框，要把分层分清楚是很难的事情。
: 我这两天在做实时推荐，哪些数据要存硬盘，哪些数据要常驻内存，
: 哪些要cache，哪些要redundant，哪些丢了也不怕，哪儿可能是
: I/O瓶颈，哪些性能无所谓，这些都要想明白，然后再选用最合适
: 的软件。我觉得我的经验比你们大部分人都多多了。
: 我见到的大部分人设计数据结构都是在选定了软件之后进行的。
: 你说的j2ee程序员，对于很多人来说lucene都是一个新东西，能有多少经验。
|
z****e
发帖数: 54598 | 22 这就是为啥scala程序不好懂
因为说不懂的会被归类成笨蛋
所谓皇帝的新衣说的就是如此吧
谁愿意承认自己是笨蛋呢？
这种秀iq的程序员应该让去搞点数学
吃点苦头
槛。
【在 d******e 的大作中提到】
: scala最后一定会比java 程序好懂。因为笨蛋程序员，裱糊匠程序员都进不了这个门槛。
|
p*****2
发帖数: 21240 | 23 大牛说到心坎了
能>
【在 w***g 的大作中提到】
: 我可能是在找骂。我的理解是一个startup的产品是需要很多iteration的。按那钱时间
: 分的话是
: 1. 拿angel fund之前：出一个糙快猛的demo，但是没有什么会最终保留到产品里。这
: 个阶段发挥作用的主要是founder，并不需要很好的代码质量。每个人拿的equity可能>
: 10%，没有工资。
: 2. 拿series A之前：有确定的磁盘数据结构(sql schema)和模块间的接口。最核心的
: 那些代码可能基本上finalize了，但是外围由很多还是糙快猛的东西。这个阶段需要一
: 两个技术大拿来确定基本框架，加起来可能有三五个全栈程序员以一当十把东西做出来
: 。这个阶段加入的人equity最多也就1~2%，一般可能也就0.x%。这时候加入的那些人基
: 本上确定了整个公司的culture，这些人几年之内不应该离职。
|
g*****g
发帖数: 34805 | 24 你这种从头写的没啥难度。我老这两次换工作面临的问题都是原来的架构已经快撑不下
去了，用户还在快速增长。如何才能重构又让现有系统24*7地跑平滑过渡。
你说的数据跟数据不一样，我在这个版上提过很多次。NoSQL是Not Only SQL，没有
Holy Grail。
【在 w***g 的大作中提到】
: 出了三层架构或者MVC这个框框，要把分层分清楚是很难的事情。
: 我这两天在做实时推荐，哪些数据要存硬盘，哪些数据要常驻内存，
: 哪些要cache，哪些要redundant，哪些丢了也不怕，哪儿可能是
: I/O瓶颈，哪些性能无所谓，这些都要想明白，然后再选用最合适
: 的软件。我觉得我的经验比你们大部分人都多多了。
: 我见到的大部分人设计数据结构都是在选定了软件之后进行的。
: 你说的j2ee程序员，对于很多人来说lucene都是一个新东西，能有多少经验。
|
w***g
发帖数: 5958 | 25 只能说你赚的也是幸苦钱。这种活我干不了。
【在 g*****g 的大作中提到】
: 你这种从头写的没啥难度。我老这两次换工作面临的问题都是原来的架构已经快撑不下
: 去了，用户还在快速增长。如何才能重构又让现有系统24*7地跑平滑过渡。
: 你说的数据跟数据不一样，我在这个版上提过很多次。NoSQL是Not Only SQL，没有
: Holy Grail。
|
c******o
发帖数: 1277 | 26 startup 架构师，和大了以后的重构架构师
这两类却是最难的了。
再加一个那种做突破性轮子的。像Spark那个MIT Associated Professor.
不过做出来了，学的也多，这种机会对工程师是多多益善。 |
c******o
发帖数: 1277 | |
g*****g
发帖数: 34805 | 28 It's like SQL DB but scales better. As great as it sounds, it is probably
expensive and doesn't scale as well as NoSQL DB. You simply can't beat CAP.
That makes it unattractive for most Internet companies.
Also if it's just like RDBMS, there's nothing much to be learned for
programmers.
【在 c******o 的大作中提到】
: BTW,有人对newsql （http://en.wikipedia.org/wiki/NewSQL)有研究的么，看起来似乎没啥人关心啊。
|
z****e
发帖数: 54598 | 29 nosql问题还多多，还处于发展阶段，newsql说的是分布式db
我觉得nosql现在还发展不到transaction和脚本就能用的地步
还有一段距离要走，比如rdd这种类似以前db的cache
spark才刚开始做
【在 c******o 的大作中提到】
: BTW,有人对newsql （http://en.wikipedia.org/wiki/NewSQL)有研究的么，看起来似乎没啥人关心啊。
|
N********n
发帖数: 8363 | 30
That's what we have been telling you every time you spammed this
board about "node & JS", have we not? HOHO.
When it comes complex tasks you'd have to use a strong-typed
serious language. There's no going around it.
【在 p*****2 的大作中提到】
: 大牛说到心坎了
:
: 能>
|
|
|
h****1
发帖数: 9 | 31 居然会有人把scala说成糙快猛．真心是在用scala么？
scala = oop + fp. 最后都是编译成java bytecode 的
如果scala糙快猛 那java(尤其java8)也同样糙快猛
讨论oop 和 fp 哪个更好没有任何意义 人家scala就是把两者都结合了 你可以封装
在o级别也可以封装在f级别 取决与你的不确定性是＂什么东西＂还是＂什么行为＂
这两个层面的封装即使oop的programmer也每天碰到. Google 的Predicate, 甚至java
core 里面自带的 ActionListener, Runnable, Callable 都带有浓重的functional的
味道
说白了scala就是把你封装的function 再套一层class/interface的壳子扔给jvm |
p*****2
发帖数: 21240 | 32
每种语言都有自己的适用范围，不然那么多公司用Java就行了，干嘛前端用Node？
【在 N********n 的大作中提到】
:
: That's what we have been telling you every time you spammed this
: board about "node & JS", have we not? HOHO.
: When it comes complex tasks you'd have to use a strong-typed
: serious language. There's no going around it.
|
c*******9
发帖数: 9032 | 33 嗯。想糙快猛的公司不会上scala。上scala的往往一开始就想以最小的浪费达到更多成
果，而不是在某阶段把前面阶段的东西丢掉。
java
【在 h****1 的大作中提到】
: 居然会有人把scala说成糙快猛．真心是在用scala么？
: scala = oop + fp. 最后都是编译成java bytecode 的
: 如果scala糙快猛 那java(尤其java8)也同样糙快猛
: 讨论oop 和 fp 哪个更好没有任何意义 人家scala就是把两者都结合了 你可以封装
: 在o级别也可以封装在f级别 取决与你的不确定性是＂什么东西＂还是＂什么行为＂
: 这两个层面的封装即使oop的programmer也每天碰到. Google 的Predicate, 甚至java
: core 里面自带的 ActionListener, Runnable, Callable 都带有浓重的functional的
: 味道
: 说白了scala就是把你封装的function 再套一层class/interface的壳子扔给jvm
|
z****e
发帖数: 54598 | 34 aglee
scala是站在巨人的肩膀上
跟糙快猛唯一的共性应该是快
但是这个快不是简化，而是拷贝，出发点比较高
不是把原来三十步弄成头两步，而是从第二十八步开始走
并不糙，糙的是脚本，var就是典型的糙
猛要看怎么定义
【在 c*******9 的大作中提到】
: 嗯。想糙快猛的公司不会上scala。上scala的往往一开始就想以最小的浪费达到更多成
: 果，而不是在某阶段把前面阶段的东西丢掉。
:
: java
|
z****e
发帖数: 54598 | 35
这句话很有道理，记下来，抄在小本上，以后琢磨琢磨
java
【在 h****1 的大作中提到】
: 居然会有人把scala说成糙快猛．真心是在用scala么？
: scala = oop + fp. 最后都是编译成java bytecode 的
: 如果scala糙快猛 那java(尤其java8)也同样糙快猛
: 讨论oop 和 fp 哪个更好没有任何意义 人家scala就是把两者都结合了 你可以封装
: 在o级别也可以封装在f级别 取决与你的不确定性是＂什么东西＂还是＂什么行为＂
: 这两个层面的封装即使oop的programmer也每天碰到. Google 的Predicate, 甚至java
: core 里面自带的 ActionListener, Runnable, Callable 都带有浓重的functional的
: 味道
: 说白了scala就是把你封装的function 再套一层class/interface的壳子扔给jvm
|
c******o
发帖数: 1277 | 36 这个有共识，oop是名词多，动词少。
fp是名词少，动词一大堆。
【在 z****e 的大作中提到】
:
: 这句话很有道理，记下来，抄在小本上，以后琢磨琢磨
: java
|
c*******9
发帖数: 9032 | 37 所以fp适合描述动态灵活的东西，oop适合相对静态的东西。
【在 c******o 的大作中提到】
: 这个有共识，oop是名词多，动词少。
: fp是名词少，动词一大堆。
|
