m******t
发帖数: 635 | |
s***o
发帖数: 2191 | |
z****e
发帖数: 54598 | 3 楼主，我发现在mobile等device上开发app好简单啊
layout的变化如果要平滑改变的话，加一个xml tag就好了
比desktop上自己搞强一万倍 |
W***o
发帖数: 6519 | 4 嗯，同感
最近在读一本Android的书，感觉这个app界面和写HTML CODE差不多
【在 z****e 的大作中提到】
: 楼主，我发现在mobile等device上开发app好简单啊
: layout的变化如果要平滑改变的话，加一个xml tag就好了
: 比desktop上自己搞强一万倍
|
s***o
发帖数: 6934 | 5 i, for one, will stay with java for just #3 |
m******t
发帖数: 635 | 6 我目前还在ios上混，作app,分辨率适配比较容易，就iphone,ipad加retina,打算过段
时间在android上开辟第二战场，不过是游戏，用游戏引擎的话，分辨率应该问题比app
小些。
你单独开个贴分享一下开发经历吧
【在 z****e 的大作中提到】
: 楼主，我发现在mobile等device上开发app好简单啊
: layout的变化如果要平滑改变的话，加一个xml tag就好了
: 比desktop上自己搞强一万倍
|
m******t
发帖数: 635 | 7 现在的语言之争已经变成了生态系统之争和hype/marketing之争了，我们不想scala变
成下一个C++浪费资源，就得出来抵制它而不是等它成主流了被动接受它，象C++一样再
被折磨一遍。话说回来，看来跟我估计的不错，这篇blog表明第一波主流吃Scala螃蟹
的开始吐槽了
其实Scala不硬扯上FP,加点语法糖，老实作个Java上的CoffeeScript说不定更好
【在 s***o 的大作中提到】
: 发包子吧。我正在想你跟二爷谁会抢先出手
|
T********i
发帖数: 2416 | 8 你这种观点我不同意。什么叫C++浪费资源？C++的发展是历史的必然。路要一步一步走
，不能一鞠而就。
任何东西，有人用，自然有他的道理。
版上很多人讨厌python。虽然我不会去用它。但是我不会拒绝XBMC。我会照样用别人现
成的python script。这些，都已经证明了，python照样能写出来大规模的，可靠的，
组织良好的项目。
你要是有本事把C++完全替换掉，算你的本事。但是我不认为有谁能。在很多领域，只
有C++能行。
只有那些基础肤浅，只会一招的才去纠结所有问题只用一种技术解决。一个螺丝钉，没
能力决策的。
【在 m******t 的大作中提到】
: 现在的语言之争已经变成了生态系统之争和hype/marketing之争了，我们不想scala变
: 成下一个C++浪费资源，就得出来抵制它而不是等它成主流了被动接受它，象C++一样再
: 被折磨一遍。话说回来，看来跟我估计的不错，这篇blog表明第一波主流吃Scala螃蟹
: 的开始吐槽了
: 其实Scala不硬扯上FP,加点语法糖，老实作个Java上的CoffeeScript说不定更好
|
d****i
发帖数: 4809 | 9 C++如果你按照plain old C++来用还好啦，不去追求那些advanced fancy features,
也不算复杂，就是在C的基础上作了一些OO的扩展，都不难。
【在 m******t 的大作中提到】
: 现在的语言之争已经变成了生态系统之争和hype/marketing之争了，我们不想scala变
: 成下一个C++浪费资源，就得出来抵制它而不是等它成主流了被动接受它，象C++一样再
: 被折磨一遍。话说回来，看来跟我估计的不错，这篇blog表明第一波主流吃Scala螃蟹
: 的开始吐槽了
: 其实Scala不硬扯上FP,加点语法糖，老实作个Java上的CoffeeScript说不定更好
|
T********i
发帖数: 2416 | 10 其实我不赞成语言的specs用太多language sugar。不过既然成标准就会有人用。这也
是没办法的。不过迄今为止还没见过太离谱的feature。定标准的绝对不是傻瓜。
【在 d****i 的大作中提到】
: C++如果你按照plain old C++来用还好啦，不去追求那些advanced fancy features,
: 也不算复杂，就是在C的基础上作了一些OO的扩展，都不难。
|
|
|
m******t
发帖数: 635 | 11 以前的硬件性能不行，需要有down to metal的高性能语言，所以C语言开始流行，后来
可能是为了GUI和大型项目的需要，C++引入OOP来降低复杂度，这个都是历史，我想版
上少有疑义。
我个人不喜欢C++的原因是，多种paradigm并存，标准库太小，连socket，xml这样的还
要第三方库，语言复杂度太高，作个东西大多数精力都在与语言斗争上，编程是种折磨
而不是享受。
当然，这个很可能是我比较弱，没有真正掌握这门语言，就像打DOOM一样，真正的高手
赤手空拳或者电锯就可以，我们这样的还是希望有把BFG，很扫一切。
【在 T********i 的大作中提到】
: 你这种观点我不同意。什么叫C++浪费资源？C++的发展是历史的必然。路要一步一步走
: ，不能一鞠而就。
: 任何东西，有人用，自然有他的道理。
: 版上很多人讨厌python。虽然我不会去用它。但是我不会拒绝XBMC。我会照样用别人现
: 成的python script。这些，都已经证明了，python照样能写出来大规模的，可靠的，
: 组织良好的项目。
: 你要是有本事把C++完全替换掉，算你的本事。但是我不认为有谁能。在很多领域，只
: 有C++能行。
: 只有那些基础肤浅，只会一招的才去纠结所有问题只用一种技术解决。一个螺丝钉，没
: 能力决策的。
|
d****i
发帖数: 4809 | 12 socket这种东西，就像thread一样，是底层的OS dependent的，所以调C的libsocket或
者Winsocket就行了。
【在 m******t 的大作中提到】
: 以前的硬件性能不行，需要有down to metal的高性能语言，所以C语言开始流行，后来
: 可能是为了GUI和大型项目的需要，C++引入OOP来降低复杂度，这个都是历史，我想版
: 上少有疑义。
: 我个人不喜欢C++的原因是，多种paradigm并存，标准库太小，连socket，xml这样的还
: 要第三方库，语言复杂度太高，作个东西大多数精力都在与语言斗争上，编程是种折磨
: 而不是享受。
: 当然，这个很可能是我比较弱，没有真正掌握这门语言，就像打DOOM一样，真正的高手
: 赤手空拳或者电锯就可以，我们这样的还是希望有把BFG，很扫一切。
|
m******t
发帖数: 635 | 13 我的意思是这些都应该是C++标准库应该提供的，90年代不提供还情有可原(当时Ｗ
indows一家独大），2000年不提供就太过分了，还要靠boost一票第三方库，严重影响
生产力。
【在 d****i 的大作中提到】
: socket这种东西，就像thread一样，是底层的OS dependent的，所以调C的libsocket或
: 者Winsocket就行了。
|
T********i
发帖数: 2416 | 14 你说的这些都有道理。缺乏标准库确实C++最被人诟病的地方。多年来各方也做了很多
努力建立标准库，boost就是其中最成功的一个。现实的问题是众口难调。标准库进展
缓慢，但不代表没有方案可以用。
当前大多成功的开源项目，比如apache，都是用C。其实比用C++实现还是要复杂一些。
但是你也知道不能抱怨C。没了它就没有现在的一切。C++线对来讲还是软柿子好捏一点。
本版推崇的node，是基于google V8的。而google V8是基于C++的。没人做C++，就没有
node。
另外，JDK也是依赖于libstdc++的。没人做这些，我们能有啥？别以为人家给你啥都收
拾好是学雷锋。迟早你都要回报的。
【在 m******t 的大作中提到】
: 以前的硬件性能不行，需要有down to metal的高性能语言，所以C语言开始流行，后来
: 可能是为了GUI和大型项目的需要，C++引入OOP来降低复杂度，这个都是历史，我想版
: 上少有疑义。
: 我个人不喜欢C++的原因是，多种paradigm并存，标准库太小，连socket，xml这样的还
: 要第三方库，语言复杂度太高，作个东西大多数精力都在与语言斗争上，编程是种折磨
: 而不是享受。
: 当然，这个很可能是我比较弱，没有真正掌握这门语言，就像打DOOM一样，真正的高手
: 赤手空拳或者电锯就可以，我们这样的还是希望有把BFG，很扫一切。
|
m******t
发帖数: 635 | 15 现在的foundation基本都是C/C++，这个大家都清楚，但是这些领域只需要少数几个大
牛就够了，大多数人不需要用C++。当然长远上看，也有问题，如果这些牛人退休的时
候，可能C++的程序员太少，产生不了新的大牛去接班，可能这个生态系统也维持不下
去了。不知道那个时候会是个什么样子，难道大家都转到类似jvm那样的虚拟机了。
点。
【在 T********i 的大作中提到】
: 你说的这些都有道理。缺乏标准库确实C++最被人诟病的地方。多年来各方也做了很多
: 努力建立标准库，boost就是其中最成功的一个。现实的问题是众口难调。标准库进展
: 缓慢，但不代表没有方案可以用。
: 当前大多成功的开源项目，比如apache，都是用C。其实比用C++实现还是要复杂一些。
: 但是你也知道不能抱怨C。没了它就没有现在的一切。C++线对来讲还是软柿子好捏一点。
: 本版推崇的node，是基于google V8的。而google V8是基于C++的。没人做C++，就没有
: node。
: 另外，JDK也是依赖于libstdc++的。没人做这些，我们能有啥？别以为人家给你啥都收
: 拾好是学雷锋。迟早你都要回报的。
|
T********i
发帖数: 2416 | 16 其实boost的ASIO做的真够烂。要是能成标准还真是奇怪了。
Java的IO刚开始也是一塌糊涂。NIO是2002年才推出的。我可以说的他的设计很好。我
很满意。
但是java的NIO也不是没有问题。迄今为止，java NIO都不能很好地处理async SSL。我
知道是为什么，估计本版知道这个事实都不多。
不能很好地处理async SSL，明显的弊病意味着在手机上基于加密SSL的推送将很困难。
这也是依赖于标准库的问题。人家不好好做，你只能受着。
其实写一个C++的socket库，透明支持SSL/TLS以及其他协议的，包括SMTP, HTTP之类的
所有可能的协议。也不是很难。就几千行，不到10000行而已。但是我知道，知道这东
西需要解决的问题在哪里的，都屈指可数，更何况真正做出来了。
BTW，我确实有自己的C++ socket库。我不打算open source。
【在 m******t 的大作中提到】
: 我的意思是这些都应该是C++标准库应该提供的，90年代不提供还情有可原(当时Ｗ
: indows一家独大），2000年不提供就太过分了，还要靠boost一票第三方库，严重影响
: 生产力。
|
d****i
发帖数: 4809 | 17 C++可能可以没有，C是永远的语言，底层的系统总要有C来build的。
【在 m******t 的大作中提到】
: 现在的foundation基本都是C/C++，这个大家都清楚，但是这些领域只需要少数几个大
: 牛就够了，大多数人不需要用C++。当然长远上看，也有问题，如果这些牛人退休的时
: 候，可能C++的程序员太少，产生不了新的大牛去接班，可能这个生态系统也维持不下
: 去了。不知道那个时候会是个什么样子，难道大家都转到类似jvm那样的虚拟机了。
:
: 点。
|
T********i
发帖数: 2416 | 18 整个linux kernel都是C做的。做C的都死绝了。各位也都不要玩了。直接回石器时代好
了。
【在 d****i 的大作中提到】
: C++可能可以没有，C是永远的语言，底层的系统总要有C来build的。
|
d****i
发帖数: 4809 | 19 所有操作系统都是C写的啊，UNIX, Linux, Windows，Mac OS, iOS, Android, 还有几
百种用于实时系统的RTOS。
【在 T********i 的大作中提到】
: 整个linux kernel都是C做的。做C的都死绝了。各位也都不要玩了。直接回石器时代好
: 了。
|
p*u
发帖数: 2454 | 20
many boost libraries are a mess, bcoz of template overuse BS...
【在 T********i 的大作中提到】
: 其实boost的ASIO做的真够烂。要是能成标准还真是奇怪了。
: Java的IO刚开始也是一塌糊涂。NIO是2002年才推出的。我可以说的他的设计很好。我
: 很满意。
: 但是java的NIO也不是没有问题。迄今为止，java NIO都不能很好地处理async SSL。我
: 知道是为什么，估计本版知道这个事实都不多。
: 不能很好地处理async SSL，明显的弊病意味着在手机上基于加密SSL的推送将很困难。
: 这也是依赖于标准库的问题。人家不好好做，你只能受着。
: 其实写一个C++的socket库，透明支持SSL/TLS以及其他协议的，包括SMTP, HTTP之类的
: 所有可能的协议。也不是很难。就几千行，不到10000行而已。但是我知道，知道这东
: 西需要解决的问题在哪里的，都屈指可数，更何况真正做出来了。
|
|
|
T********i
发帖数: 2416 | 21 呵呵，说太多也有不好的地方。mimisoft当然知道很多。但是像goodbug和zhaoce那样
的可能只知道能run web的。RTOS就不要跟他们说了。
【在 d****i 的大作中提到】
: 所有操作系统都是C写的啊，UNIX, Linux, Windows，Mac OS, iOS, Android, 还有几
: 百种用于实时系统的RTOS。
|
d****i
发帖数: 4809 | 22 用过几种不同的RTOS，真是世界之大，无奇不有，各有特色，精妙不已。
【在 T********i 的大作中提到】
: 呵呵，说太多也有不好的地方。mimisoft当然知道很多。但是像goodbug和zhaoce那样
: 的可能只知道能run web的。RTOS就不要跟他们说了。
|
T********i
发帖数: 2416 | 23 和你握一下手。
我现在正在玩SiliconLabs和TI的RF chips。其实RTOS的优势就是简单。
【在 d****i 的大作中提到】
: 用过几种不同的RTOS，真是世界之大，无奇不有，各有特色，精妙不已。
|
p*u
发帖数: 2454 | 24
RF market data feeds can be impacted by the weather a lot, not very reliable
...
【在 T********i 的大作中提到】
: 和你握一下手。
: 我现在正在玩SiliconLabs和TI的RF chips。其实RTOS的优势就是简单。
|
T********i
发帖数: 2416 | 25 传统的还不能丢。一旦RF丢包，2-3毫秒以后光纤的数据就跟上了。等于费两遍事还要
多。但是我已经完成了。
我玩的这些RF chips是consumer electronics用的。这年头，靠一张大嘴忽悠过活的多
，真正干活的太少了。能多做点我就尽量多做一点。毕竟都是迄今没人做好的。
reliable
【在 p*u 的大作中提到】
:
: RF market data feeds can be impacted by the weather a lot, not very reliable
: ...
|
c******o
发帖数: 1277 | 26 看看讨论就知道，只有讨论，哪里是一面倒的批判。
那面又有时还未定。
唯一同意的就是compiler 慢。
我们才刚开始用scalaz，感觉很好。
我们内部不用dsl，由于有强大的type system,我们可以放心做很抽象的reusable code
，static type system 很好很强大。
【在 m******t 的大作中提到】
: http://overwatering.org/blog/2013/12/scala-1-star-would-not-pro
|
s***o
发帖数: 2191 | 27 同感。讨论里面的营养成分更多。这篇文章的作者给人的感觉是拿了一本“Mastering
Scala in 24-hours”的书比划了一晚上后上来发牢骚的，而不像一位用了6年Scala的老
鸟。
你们为啥不直接上clojure？
code
【在 c******o 的大作中提到】
: 看看讨论就知道，只有讨论，哪里是一面倒的批判。
: 那面又有时还未定。
: 唯一同意的就是compiler 慢。
: 我们才刚开始用scalaz，感觉很好。
: 我们内部不用dsl，由于有强大的type system,我们可以放心做很抽象的reusable code
: ，static type system 很好很强大。
|
m******t
发帖数: 635 | 28 这个版上你是少数的scala实战派，欢迎多多发言。
能大概说说你们的scala项目的大小么，比如多少行scala code，编译一次要多久？
另外，好像很多人很讨厌scalaz，说它玩的太花，能给评论下么？
code
【在 c******o 的大作中提到】
: 看看讨论就知道，只有讨论，哪里是一面倒的批判。
: 那面又有时还未定。
: 唯一同意的就是compiler 慢。
: 我们才刚开始用scalaz，感觉很好。
: 我们内部不用dsl，由于有强大的type system,我们可以放心做很抽象的reusable code
: ，static type system 很好很强大。
|
g*****g
发帖数: 34805 | 29 我只知道能run web没错，偏偏这个你不行，可笑魏公公你非要在不懂的东西上扯蛋找
打。
【在 T********i 的大作中提到】
: 呵呵，说太多也有不好的地方。mimisoft当然知道很多。但是像goodbug和zhaoce那样
: 的可能只知道能run web的。RTOS就不要跟他们说了。
|
c******o
发帖数: 1277 | 30 现在还没多少10万左右，但是每次新feature就会增加,每次refactor就会减少。
scalaz is not for everyone. 我们用了它的validation abstraction，还有generic
的applicative
scalaz不是花，是太抽象了，没想到之前你都不知道为啥要它，想到之后你会说：“靠
，这个原来和那个是一样的，还能这么做，不用写两遍了”
【在 m******t 的大作中提到】
: 这个版上你是少数的scala实战派，欢迎多多发言。
: 能大概说说你们的scala项目的大小么，比如多少行scala code，编译一次要多久？
: 另外，好像很多人很讨厌scalaz，说它玩的太花，能给评论下么？
:
: code
|
|
|
c******o
发帖数: 1277 | 31 static type 是我们的must have
我们的java/ruby 人才多
Mastering
的老
【在 s***o 的大作中提到】
: 同感。讨论里面的营养成分更多。这篇文章的作者给人的感觉是拿了一本“Mastering
: Scala in 24-hours”的书比划了一晚上后上来发牢骚的，而不像一位用了6年Scala的老
: 鸟。
: 你们为啥不直接上clojure？
:
: code
|
m******t
发帖数: 635 | 32 10万行也算是很大的scala应用了吧，编译真的那么慢么? 写blog这个哥们估计也就是
小打小闹的，编译一次加run tests也要快1分半钟，他是不是设置有问题？
我好像记得去年什么时候Scala的作者martin说scala编译速度大概是1000行 每秒，那
么你们项目大概编译的话大概100秒，当然现在硬件更快了，乐观估计也要2０秒左右，
好像也还可以接受。
generic
【在 c******o 的大作中提到】
: 现在还没多少10万左右，但是每次新feature就会增加,每次refactor就会减少。
: scalaz is not for everyone. 我们用了它的validation abstraction，还有generic
: 的applicative
: scalaz不是花，是太抽象了，没想到之前你都不知道为啥要它，想到之后你会说：“靠
: ，这个原来和那个是一样的，还能这么做，不用写两遍了”
|
g*****g
发帖数: 34805 | 33 看你写啥的，写后端，几百行写了，再测一测test case，可以接受。要是写前端，改
一行
就得到UI上看看好不好，编译慢就太难受了。
【在 m******t 的大作中提到】
: 10万行也算是很大的scala应用了吧，编译真的那么慢么? 写blog这个哥们估计也就是
: 小打小闹的，编译一次加run tests也要快1分半钟，他是不是设置有问题？
: 我好像记得去年什么时候Scala的作者martin说scala编译速度大概是1000行 每秒，那
: 么你们项目大概编译的话大概100秒，当然现在硬件更快了，乐观估计也要2０秒左右，
: 好像也还可以接受。
:
: generic
|
b***e
发帖数: 1419 | 34 这篇前后矛盾。打回重写。
【在 g*****g 的大作中提到】
: 我只知道能run web没错，偏偏这个你不行，可笑魏公公你非要在不懂的东西上扯蛋找
: 打。
|
b***e
发帖数: 1419 | 35 你写这些monadic code可维护性怎么样? 比如说你走了别人还搞得动么?
code
【在 c******o 的大作中提到】
: 看看讨论就知道，只有讨论，哪里是一面倒的批判。
: 那面又有时还未定。
: 唯一同意的就是compiler 慢。
: 我们才刚开始用scalaz，感觉很好。
: 我们内部不用dsl，由于有强大的type system,我们可以放心做很抽象的reusable code
: ，static type system 很好很强大。
|
m******t
发帖数: 635 | 36 那倒是，scala应该主要还是后端。要是用新出来的那个scala.js写前端的话，估计要
郁闷死。
话说ClojureScript在我的老netbook上(atom n270)编译代码(几百行，clojurescript
-> javascript)都只要0.x秒。
【在 g*****g 的大作中提到】
: 看你写啥的，写后端，几百行写了，再测一测test case，可以接受。要是写前端，改
: 一行
: 就得到UI上看看好不好，编译慢就太难受了。
|
b***e
发帖数: 1419 | 37 你查一下作者的简历就知道scala原本是学院派的产物。里面有很强的Haskell的血脉。
【在 m******t 的大作中提到】
: 现在的语言之争已经变成了生态系统之争和hype/marketing之争了，我们不想scala变
: 成下一个C++浪费资源，就得出来抵制它而不是等它成主流了被动接受它，象C++一样再
: 被折磨一遍。话说回来，看来跟我估计的不错，这篇blog表明第一波主流吃Scala螃蟹
: 的开始吐槽了
: 其实Scala不硬扯上FP,加点语法糖，老实作个Java上的CoffeeScript说不定更好
|
m******t
发帖数: 635 | 38 其实如果scala老实做个F# on JVM说不定我会选它。
【在 b***e 的大作中提到】
: 你查一下作者的简历就知道scala原本是学院派的产物。里面有很强的Haskell的血脉。
|
c******o
发帖数: 1277 | 39 我们刚setup了incremental/continues build machine
TDD prod的build 不用太考虑时间。
自己的mac pro上其实很快，没有100秒，sbt只compile需要的，也是incremental的。
10万应该不包括任何library（都是jar），但是包括comment/test（很多）
【在 m******t 的大作中提到】
: 10万行也算是很大的scala应用了吧，编译真的那么慢么? 写blog这个哥们估计也就是
: 小打小闹的，编译一次加run tests也要快1分半钟，他是不是设置有问题？
: 我好像记得去年什么时候Scala的作者martin说scala编译速度大概是1000行 每秒，那
: 么你们项目大概编译的话大概100秒，当然现在硬件更快了，乐观估计也要2０秒左右，
: 好像也还可以接受。
:
: generic
|
c******o
发帖数: 1277 | 40 TDD的，comment也多，想知道是啥，看test code就知道了。
【在 b***e 的大作中提到】
: 你写这些monadic code可维护性怎么样? 比如说你走了别人还搞得动么?
:
: code
|
|
|
m******t
发帖数: 635 | 41 你们公司的编程culture真的很赞!
【在 c******o 的大作中提到】
: TDD的，comment也多，想知道是啥，看test code就知道了。
|
c******o
发帖数: 1277 | 42 the author's resume has 2 humble lines:
the author of java generic
the author of scala language
不觉得有多学院，这都学院，那没啥不是了。
【在 b***e 的大作中提到】
: 你查一下作者的简历就知道scala原本是学院派的产物。里面有很强的Haskell的血脉。
|
m******t
发帖数: 635 | 43 发现一个很搞笑的fact, 对比一下就很有趣:
微软研究院的Don Syme
the author of C# Generics
and
the author of F# (ML on .NET)
【在 c******o 的大作中提到】
: the author's resume has 2 humble lines:
: the author of java generic
: the author of scala language
: 不觉得有多学院，这都学院，那没啥不是了。
|
c******o
发帖数: 1277 | 44 scala的sbt我虽然不喜欢（太花，太复杂）但是dynamic incremental build做得不错
，要是就是小改，其实很快。
【在 g*****g 的大作中提到】
: 看你写啥的，写后端，几百行写了，再测一测test case，可以接受。要是写前端，改
: 一行
: 就得到UI上看看好不好，编译慢就太难受了。
|
c******o
发帖数: 1277 | 45 Generics => FP/OO hybrid?
那c++也快了。。。。
【在 m******t 的大作中提到】
: 发现一个很搞笑的fact, 对比一下就很有趣:
: 微软研究院的Don Syme
: the author of C# Generics
: and
: the author of F# (ML on .NET)
|
g*****g
发帖数: 34805 | 46 All pros and cons for a flexible language like Scala has been debated. The
view of it is very bipolar. Enthusiasts are dying for it, criticists don't
even want to finish the tutorial. There's no doubt it's gaining momentum,
but at the same time not fast enough to be mainstream in near future.
Personally I think it will be like Perl on JVM. A niche language that is
powerful for certain libraries, but its flexibility kills the readability
eventually. |
c******o
发帖数: 1277 | 47 scala 2.11 有很多改变，Rod from Spring does have a huge impact.
scala 2.11会focus 在faster compiler, more flexible module (你可以定制你用的
scala 的feature set)
Martin 最近的工作方向是优化type system，加快编译时间。。。。
【在 g*****g 的大作中提到】
: All pros and cons for a flexible language like Scala has been debated. The
: view of it is very bipolar. Enthusiasts are dying for it, criticists don't
: even want to finish the tutorial. There's no doubt it's gaining momentum,
: but at the same time not fast enough to be mainstream in near future.
: Personally I think it will be like Perl on JVM. A niche language that is
: powerful for certain libraries, but its flexibility kills the readability
: eventually.
|
z****e
发帖数: 54598 | 48 如果没有了物理学
你现在还搞什么cs？
别扯淡了，回家种田去
那你为什么不去学物理呢？
因为搞物理没钱
像dsb和弃婴一样，天天在实验室里面
丫要多苦逼有多苦逼了
用你的逻辑说就是
没有人搞物理，我们能有啥？
别以为人家给你啥都收拾好是学雷锋
迟早你都要回报的
好了，问题来了，老魏你打算什么时候报效物理学专业？
点。
【在 T********i 的大作中提到】
: 你说的这些都有道理。缺乏标准库确实C++最被人诟病的地方。多年来各方也做了很多
: 努力建立标准库，boost就是其中最成功的一个。现实的问题是众口难调。标准库进展
: 缓慢，但不代表没有方案可以用。
: 当前大多成功的开源项目，比如apache，都是用C。其实比用C++实现还是要复杂一些。
: 但是你也知道不能抱怨C。没了它就没有现在的一切。C++线对来讲还是软柿子好捏一点。
: 本版推崇的node，是基于google V8的。而google V8是基于C++的。没人做C++，就没有
: node。
: 另外，JDK也是依赖于libstdc++的。没人做这些，我们能有啥？别以为人家给你啥都收
: 拾好是学雷锋。迟早你都要回报的。
|
z****e
发帖数: 54598 | 49 这个社会的发展就是对各层面封装的结果
现在搞ee的批量转行cs，为啥？
因为ee提供不了那么多工作机会了
而且天朝等第三世界国家，要抄也都抄了
美帝的竞争优势在被逐步削弱
就像当初做汽车一样，最早也就是美国德国等国家能做
后来日本学会了，韩国也学会了，美国的汽车产业就开始苦逼了
我们出生之前，在美国汽车行业做工人，那是很幸福的
一个人干活，全家管饱，下班回来看看电视，吃饭睡觉
很惬意的，今天如果还在美国汽车行业做工人
那前景非常堪忧的
cs也是一样的，c这一层搞到现在，再搞又能怎样？该搞的都搞了
就算有漏网之鱼，那也不过是漏网之鱼而已
80％的事别人都做了，剩下20％，你要投入80％的精力去搞，还不一定有什么结果
但是新兴领域不一样，新兴领域一片空白，大量缺乏人手
有人来就能干活，就需要人力干活，80％的事都还没有人搞过
那么这个时候投入20％，就很容易有高回报
任何一个领域，在其毁灭还有诞生初期，都是有巨额回报的时候
应该毫不犹豫抓住机会，投入这些领域，攫取高额回报
现在social website和big data是在诞生初期，慢慢爬向顶端
而mobile则是毁灭的时候，一批搞通信的公司倒闭
但是毁灭也同时意味着重生，因为总要有公司搞这个，所以也创造出大量的机会
这些都是新人笑，新人笑得越开心，旧人就哭得越痛苦
以前给北电，摩托罗拉，诺基亚这些公司打工的，那现在就是哭的时候
【在 d****i 的大作中提到】
: C++可能可以没有，C是永远的语言，底层的系统总要有C来build的。
|
b***e
发帖数: 1419 | 50 http://lampwww.epfl.ch/~odersky/
Before authoring scala, odersky is mostly a type theorist. 纯学院派的。他可
能是转实用型转的最好的。
【在 c******o 的大作中提到】
: the author's resume has 2 humble lines:
: the author of java generic
: the author of scala language
: 不觉得有多学院，这都学院，那没啥不是了。
|
|
|
z****e
发帖数: 54598 | 51 最后一句话非常经典
现在就看谁能做一个java上的coffeescript了
谁做出来谁就能成功
【在 m******t 的大作中提到】
: 现在的语言之争已经变成了生态系统之争和hype/marketing之争了，我们不想scala变
: 成下一个C++浪费资源，就得出来抵制它而不是等它成主流了被动接受它，象C++一样再
: 被折磨一遍。话说回来，看来跟我估计的不错，这篇blog表明第一波主流吃Scala螃蟹
: 的开始吐槽了
: 其实Scala不硬扯上FP,加点语法糖，老实作个Java上的CoffeeScript说不定更好
|
z****e
发帖数: 54598 | 52 老魏我跟你的区别在于
我不懂的不会去装懂，你不懂的你会装懂
要不你说说你懂不懂怎么搞website？
我就明说了，你不懂怎么做website，你服气不服气？
你说的恰好就是怎么做website，我告诉你的是
你那一套是不行的，不适合做website
想起当年的一个笑话，老大问，你们上班堵车不堵车啊？
都说很堵，我说，那可以早一点来
老大说，你要是四点来，肯定不会堵
老魏你就是属于那种为了避开堵车，四点就跑来上班的家伙
凡事，过犹不及
【在 T********i 的大作中提到】
: 呵呵，说太多也有不好的地方。mimisoft当然知道很多。但是像goodbug和zhaoce那样
: 的可能只知道能run web的。RTOS就不要跟他们说了。
|
z****e
发帖数: 54598 | 53 c++不就是正在被替换中么？
现在java，python这些做的
当初不就是c++在做么？
我们刚刚在案例中用java替换掉你的c++去写铁道部的website
你忘记了？你忘记一开始你信誓旦旦地说要用c++去写了？
后来又改口说要用java了？
基础浅用一招去解决问题，这个倒也没错
因为我们需要大量的人手来帮忙，就是要让外行的转行的也能够参与社会建设
早就说了，这些人你不要，我要
草木皆可为剑，大妈文科生皆可为码农
【在 T********i 的大作中提到】
: 你这种观点我不同意。什么叫C++浪费资源？C++的发展是历史的必然。路要一步一步走
: ，不能一鞠而就。
: 任何东西，有人用，自然有他的道理。
: 版上很多人讨厌python。虽然我不会去用它。但是我不会拒绝XBMC。我会照样用别人现
: 成的python script。这些，都已经证明了，python照样能写出来大规模的，可靠的，
: 组织良好的项目。
: 你要是有本事把C++完全替换掉，算你的本事。但是我不认为有谁能。在很多领域，只
: 有C++能行。
: 只有那些基础肤浅，只会一招的才去纠结所有问题只用一种技术解决。一个螺丝钉，没
: 能力决策的。
|
m******t
发帖数: 635 | 54 Another Scala rant on HN - Google Groups
https://news.ycombinator.com/item?id=6838836
关于scala的茶话会第二天 |
g*****g
发帖数: 34805 | 55 Rod and Martin are both programmers I admire. However, this is a language,
not a framework. A person can shape a framework, a language, not so much.
You can't even remove features already existing in a language (or at least
deprecate over a long period of time), otherwise it's compilation issue and
lousy foul complaint in the community. Scala is already so flexible that
more features hardly make it better. I am sure if the community settles down
on the language, and focus on the quality of frameworks instead, it will be
more useful. But it's always easier said than done. I kind of feel the buzz
in the industry is fading away, with Node and Clojure taking away fair
share of that buzz.
【在 c******o 的大作中提到】
: scala 2.11 有很多改变，Rod from Spring does have a huge impact.
: scala 2.11会focus 在faster compiler, more flexible module (你可以定制你用的
: scala 的feature set)
: Martin 最近的工作方向是优化type system，加快编译时间。。。。
|
c******o
发帖数: 1277 | 56 I just feel so differently, now it is the peak of criticism for scala on
popular programming sites(maybe still more to come).
This peak itself is a evidence Scala is hugely successful in a lot area/
companies, Node/Clojure still not there yet.
C++/Java/Ruby all had this peak of criticism before, and then a long time
rise.
After the initial resistance, most people will get to use it silently.
and
down
be
buzz
【在 g*****g 的大作中提到】
: Rod and Martin are both programmers I admire. However, this is a language,
: not a framework. A person can shape a framework, a language, not so much.
: You can't even remove features already existing in a language (or at least
: deprecate over a long period of time), otherwise it's compilation issue and
: lousy foul complaint in the community. Scala is already so flexible that
: more features hardly make it better. I am sure if the community settles down
: on the language, and focus on the quality of frameworks instead, it will be
: more useful. But it's always easier said than done. I kind of feel the buzz
: in the industry is fading away, with Node and Clojure taking away fair
: share of that buzz.
|
c******o
发帖数: 1277 | 57 In fact, Scala is the only real static language choice on JVM other than
Java, and it is more fun and more powerful than Java (maybe messier)
I will definitely go to a better language if there is one match static typed
/on JVM.
and
down
be
buzz
【在 g*****g 的大作中提到】
: Rod and Martin are both programmers I admire. However, this is a language,
: not a framework. A person can shape a framework, a language, not so much.
: You can't even remove features already existing in a language (or at least
: deprecate over a long period of time), otherwise it's compilation issue and
: lousy foul complaint in the community. Scala is already so flexible that
: more features hardly make it better. I am sure if the community settles down
: on the language, and focus on the quality of frameworks instead, it will be
: more useful. But it's always easier said than done. I kind of feel the buzz
: in the industry is fading away, with Node and Clojure taking away fair
: share of that buzz.
|
g*****g
发帖数: 34805 | 58 I don't know man. The criticism was like C++. But at that time, C++ had no
competition. It was the only boy in town, SmallTalk never really went
anywhere.
What's Scala's strength today? Akka is a prime example. Concurrency
framework, FP's sweet spot. But Clojure does that too, and easily a more
pure FP language. Of course Scala is static and it should perform better.
But that's probably not the most important thing for a concurrency framework
.
Beyond that scope, Scala, also a static language, is competing head-to-head
against Java. But I don't see it winning it for all the cons aforementioned.
I picked up Scala 3 years ago when Akka was getting buzz but still in
infantry. 3 years later, Scala hasn't made a big noise. IMHO, RoR, Node both
had a much stronger momentum. I am not writing it off, but I stay skeptical
of its future.
typed
【在 c******o 的大作中提到】
: In fact, Scala is the only real static language choice on JVM other than
: Java, and it is more fun and more powerful than Java (maybe messier)
: I will definitely go to a better language if there is one match static typed
: /on JVM.
:
: and
: down
: be
: buzz
|
c******o
发帖数: 1277 | 59 The most important reason for me to choose a static type language, is that,
"I am not a best programmer"
Static type does make big system much easier, and also does make more people
work together easier.
In fact for clojure, they promote "static type" at module boundary.
for me ideally is that node.js for web tier, Scala for backend, and clojure
for scripting
(but everyone use Restful with json for mobile world anyway, not much space
for node)
framework
head
aforementioned.
【在 g*****g 的大作中提到】
: I don't know man. The criticism was like C++. But at that time, C++ had no
: competition. It was the only boy in town, SmallTalk never really went
: anywhere.
: What's Scala's strength today? Akka is a prime example. Concurrency
: framework, FP's sweet spot. But Clojure does that too, and easily a more
: pure FP language. Of course Scala is static and it should perform better.
: But that's probably not the most important thing for a concurrency framework
: .
: Beyond that scope, Scala, also a static language, is competing head-to-head
: against Java. But I don't see it winning it for all the cons aforementioned.
|
g*****g
发帖数: 34805 | 60 I am not against static language for big system. I just believe dynamic
language can work for a framework. Because framework is not really big and
it can be handled by a small team. And a framework on JVM doesn't require
the users to use the same language. Most users of Storm would be Java users,
for example.
Dynamic language's strength is always scripting. I agree on that too.
Everyone is using Rest these days. But you can have server side MVC
frameworks using rest service. That's still the status quo. Maybe when
client MVC is stronger enough it will change. But I don't know much on front
tier and I can't comment on its future.
,
people
clojure
space
【在 c******o 的大作中提到】
: The most important reason for me to choose a static type language, is that,
: "I am not a best programmer"
: Static type does make big system much easier, and also does make more people
: work together easier.
: In fact for clojure, they promote "static type" at module boundary.
: for me ideally is that node.js for web tier, Scala for backend, and clojure
: for scripting
: (but everyone use Restful with json for mobile world anyway, not much space
: for node)
:
|
|
|
b***e
发帖数: 1419 | 61 I in fact do not expect to see either clojure or scala survive for long (
they actually remind me of dojo ajax framework). Common Lisp syntax cannot
be appreciated by common developers. Scala's complication in language
features and type inference will eventually be a problem for common
developers as well. You, apparently, are among top level professionals as a
software engineer. I do not expect the vast majority of software
developers to reach your level of skills, interests and enthusiasm. I'd put
more bet on a better Java.
On the other hand, that's why things like php/ruby/python/node to prevail (
so far better than scala/clojure). They are so simple (for starters at
least) and almost anybody can pick it up pretty quickly. I see it start to
converge to node right now. I guess ideally for me, it's node 4 online +
java 4 offline.
,
people
clojure
space
【在 c******o 的大作中提到】
: The most important reason for me to choose a static type language, is that,
: "I am not a best programmer"
: Static type does make big system much easier, and also does make more people
: work together easier.
: In fact for clojure, they promote "static type" at module boundary.
: for me ideally is that node.js for web tier, Scala for backend, and clojure
: for scripting
: (but everyone use Restful with json for mobile world anyway, not much space
: for node)
:
|
d****i
发帖数: 4809 | 62 大拿说的好。
cannot
a
put
【在 b***e 的大作中提到】
: I in fact do not expect to see either clojure or scala survive for long (
: they actually remind me of dojo ajax framework). Common Lisp syntax cannot
: be appreciated by common developers. Scala's complication in language
: features and type inference will eventually be a problem for common
: developers as well. You, apparently, are among top level professionals as a
: software engineer. I do not expect the vast majority of software
: developers to reach your level of skills, interests and enthusiasm. I'd put
: more bet on a better Java.
: On the other hand, that's why things like php/ruby/python/node to prevail (
: so far better than scala/clojure). They are so simple (for starters at
|
g*****g
发帖数: 34805 | 63 Haha, you come to the party a little late, but finally we have something we
can agree on.
cannot
a
put
【在 b***e 的大作中提到】
: I in fact do not expect to see either clojure or scala survive for long (
: they actually remind me of dojo ajax framework). Common Lisp syntax cannot
: be appreciated by common developers. Scala's complication in language
: features and type inference will eventually be a problem for common
: developers as well. You, apparently, are among top level professionals as a
: software engineer. I do not expect the vast majority of software
: developers to reach your level of skills, interests and enthusiasm. I'd put
: more bet on a better Java.
: On the other hand, that's why things like php/ruby/python/node to prevail (
: so far better than scala/clojure). They are so simple (for starters at
|
b***e
发帖数: 1419 | 64 That being said, I give my best wish for Scala to prove me wrong. I like
Odersky the person, powerful yet humble.
we
【在 g*****g 的大作中提到】
: Haha, you come to the party a little late, but finally we have something we
: can agree on.
:
: cannot
: a
: put
|
