V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  YuJianrong  ›  全部回复第 13 页 / 共 25 页
回复总数  499
1 ... 9  10  11  12  13  14  15  16  17  18 ... 25  
2016-04-19 01:00:38 +08:00
回复了 cevincheung 创建的主题 问与答 JS 白痴问个倒计时的问题
setTimeout 时间延迟比较长的原因很简单……因为标准就是这样的……

https://html.spec.whatwg.org/multipage/webappapis.html#timers

8. If nesting level is greater than 5, and timeout is less than 4, then increase timeout to 4.

nesting level 是指这个 timer 是被另一个 timer 回调函数递归调用的深度,前 4 个递归的 timeout 按原时间调用,第 5 个开始延时会增加到至少 4ms

当然,除了这个因素之外,还有你的各种处理也会消耗时间;回调也是在 JS 线程开始运转,消息队列在 timer 之前跑完才跑,所以间隔当然不只是设置的那点时间了。

不用说正确方法当然是取时间来处理。
根据这篇文章: http://superuser.com/questions/432838/hibernate-between-os-x-and-bootcamp-win-7

貌似 OSX 的 hibernate 是不能切 bootcamp 的, hibernate 了起来一定是 osx 。
2016-04-15 20:27:42 +08:00
回复了 wsph123 创建的主题 分享创造 ❄️「鲁迅追番」 - 简单好用的追番工具 ( ›´ω`‹ )
求不用微博做通用账号登录……

微博这货授权总是要允许被授权方以授权方名义发微博,上过几次当之后我就再也不用微博作为通用账号登陆了……
2016-04-10 23:45:49 +08:00
回复了 83f420984 创建的主题 职场话题 感觉自己的运气已经背到极点了
@TTry ……
2016-04-10 23:43:20 +08:00
回复了 83f420984 创建的主题 职场话题 感觉自己的运气已经背到极点了
@jarlyyn 当然了,非科班出身,看过数据结构人工智能计算机组成原理 OOP/FP/SE ,确实各种东西也就懂了,不过这和在科班学习有啥差别…… 你要说计算机科学才多久历史,我觉得半个世纪也不能算太短吧……

@Bardon 确实歪楼了,顺便一提我其实是有点偏理的工科出身……即使是工科也还是学了不少东西的嘛。
回到主楼,我觉得楼主应该思考一下自己真的是不是喜欢做(前端)开发,毕竟真心热爱的话, html/css/js 并没有太多的内容,自己找资料整天研究各种东西进步还是会很快的(就如前面一位的意思,学前端也不需要啥基础)。如果没有这样的心思,但还是想混开发的话,报个班强迫自己学习大概是个更好的选择吧……
2016-04-10 22:32:34 +08:00
回复了 83f420984 创建的主题 职场话题 感觉自己的运气已经背到极点了
@jarlyyn 哈哈哈,说得好像每个前端都能做到 TJ 那样呢……找个特别厉害的特例来有什么用啊,又不能改变非科班出身前端普遍废柴的事实。

既然你都不知道科班那么多年究竟学了些什么东西的话,当然也不知道有什么前端工作是需要科班基础才能快速学会的了……

说得更明白点,既然 JS 语言是一种图灵完备的程序设计语言,那么就能做任何图灵完备的计算机语言能做的事情,而在这方面的研究,包括图形学、人工智能、编译原理、软件工程等等理论,你觉得它们永远都和前端无缘吗?你觉得真要做的时候,没有科班学习的基础也能轻松上手吗?

比如 three3d 、 typescript 、 mocha 、 angular 、 react 、 metor ,要做出甚至只是用好这些东西,没有科班基础都要困难很多,其实这些东西,才是拉开一个优秀前端或者说一个优秀开发人员与其他人距离的东西。
2016-04-10 19:09:05 +08:00
回复了 83f420984 创建的主题 职场话题 感觉自己的运气已经背到极点了
@jarlyyn 胡说什么前端不需要科班基础,正是因为这种低水平前端太多,才让前端一直在开发者眼中是一种非常低端的印象(不过也是好事,大量废柴“前端”让我们这些科班进入的人能明显地脱颖而出,哈哈)。

没有扎实的科班基础,前端做到一定程度水平就上不去了,最后只会像最近微博上火起来的“真啊当”那样被人当成笑话看……
2016-03-24 00:27:01 +08:00
回复了 wjfz 创建的主题 Node.js 微博上说 npm 咋滴了?
蛮同情后端的,一直都没什么新东西……
2016-03-21 13:57:44 +08:00
回复了 livecoding 创建的主题 程序员 WebAssembly 的介绍
@wizardforcel 真是胡说八道。

没有看过我重复了数次了么? webasm 只是 asm.js 的二进制形式,照你这样说我把机器码反汇编成汇编代码,这样你也能说汇编是高级语言吗?所以汇编“不是 bytecode ,就会有编译上的种种问题”,什么问题?

另外你所幻想的 java 加入前端行列,不需要 webasm(其实 webasm 也没用,毕竟 java 不是 native language),在 2006 年 Google 推出 Google Web Toolkit 的时候就已经成现实了,发展情况有目共睹。

再重复一下: webasm 脱胎于 asm.js ,是一个用于前端密集计算的解决方案,设计目标并不是取代 JS ,在可预见的未来也不会取代 JS 。
2016-03-21 12:38:34 +08:00
回复了 livecoding 创建的主题 程序员 WebAssembly 的介绍
@sagnitude
webasm 主要带来的是代码本身大小和 parse 时间的优化,看起来你的场景需要的是大量位操作和数字运算,但代码不一定非常巨大,如果是这样的话用 asm.js 应该已经能得到可观的优化了。如果不想用 emscripten 来把 C/C++翻译成 asm.js 的话,也可以用其他语言直接转译 asm.js 来做 http://jlongster.com/Compiling-LLJS-to-asm.js,-Now-Available-

webasm 相比 asm.js 带来的是代码加载和解析的优势,没有这方面的问题的话直接用 asm.js 就好了。
2016-03-21 11:42:30 +08:00
回复了 livecoding 创建的主题 程序员 WebAssembly 的介绍
@wizardforcel 这语气听起来挺让人不爽的,我在很早就说过这相当于 JVM ,只是用这个来说这种方案并没有动摇最原生语言( java )的地位而已。

@sagnitude 这确实是一个非常合理的应用场景,解 zip 肯定是可以通过 Asm.js/websam 加速的,不过提到 parse json 的话, asm 方案不会有改变(其实 parse json 本来就是原生 API ),如果你说要把 3D 数据压缩成二进制格式的话,其实即使不用 Asm.js/websam 也是可以做的,现在的浏览器已经广泛支持 TypedArray 标准(这个标准就是做 webGLES 的 khronos 提出的),可以用 JS 来方便地处理二进制数据。简单来说就是现有技术已经可以极大提高你的应用场景的效率了。
2016-03-21 11:30:25 +08:00
回复了 livecoding 创建的主题 程序员 WebAssembly 的介绍
@tennix 哎……我觉得既然不懂前端就不要这么强行回答吧……
[看看前端技术变化就知道前端有多么糟糕了] 我一直看前端技术变化怎么只觉得越来越好呢?变化快不是什么坏事,变化快说明前端受到越来越多的重视,所以有越来越多的人带着各种思想进入这个领域,难道你觉得一个技术要向 2011 年之前的 C++那样几乎毫无变化才是好技术吗(然而现在照样在剧烈变化)。

[第一这是一门高级语言;第二这门语言设计上有太多的坑;第三运行性能很成问题] JS 确实有坑,但要说多的话其实也不多,而且 es5, es6 之后就填了不少,总的来说完全够不上“太多”这样的定义,一开始学习踩上几个真不算什么。性能上现在 JIT 的 JS 距离原生语言也就一个数量级而已, asm.js 就在一个数量级以内了,说实话比起大多数语言( python, ruby )来说已经好多了。

[TS 和 CS 转 JS 效果当然很不错,因为它们本身就是在 JS 基础之上构建的(ts/cs 编译器都是 js 写的)] 说实话语言和它的编译器用什么来写其实一点关系都没有(而且其实 CS 编译器早期版本是用 ruby 写的,后期是 cs ; TS 编译器在一开始推出就是 TS 写的),其实编译器自举只是对编译器的一种验证而已,并不能说明任何事情……这两个语言和其他语言 compile to JS 方案的最大区别只是这两个语言设计上就为 JS 特性做了裁剪而已,其他语言编译出来比较恶心只是因为没有裁剪那就只有比较恶心的方式来模拟……

[只有出来一个低级底层一点的语言,其它语言才可以无痛 compile/transpile 到这个目标语言...没记错的话 asm.js 只是 js 的一个子集,而且似乎并不是一个标准] 首先 asm.js 当然是一个标准,虽然是 Mozzila 提出来的,最新的浏览器除了 Safari 外都对 asm.js 有优化支持,其次其实 Asm.js 就是你要的那个底层语言……其实 Webasm 只是 asm.js 的二进制版而已……

[有了 webassembly 这种格式,以前可能需要十几兆甚至更大的 JS 才能实现的功能,以后经过编译优化可能只需要几百 k ,性能也会有很大提升] 这个真的就是纯 YY 了,我上面已经说了其实 webasm 只是 asm.js 的二进制形式,大小其实不会有本质的变化,根据官方 FAQ 的数据,二进制形式的代码大小也有 asm.js 的 1/3 大小, gzip 后差距更小,二进制的大小差不多是 Asm.js 版的 70%。而性能更是完全没有变化,因为其实还是 Asm.js ,只是二进制版而已…… webasm 只是有 parse 效率上的优化……

简单来说, WebAsm 不是非 JS 开发人员的银弹,如果想做前端,还是请使用 JS/TS/CS ,这东西在可见的未来并不会动摇 JS 的地位,只能作为一个高性能计算的解决方案而已。
2016-03-21 00:39:16 +08:00
回复了 livecoding 创建的主题 程序员 WebAssembly 的介绍
@wizardforcel 顺便再重复一下,“之前 js 地位不动摇是因为它是浏览器唯一指定的脚本语言。现在有 webasm 了。 ”——这个观点的错误在于 webasm 其实还是 JS ,只不过是二进制的 JS 而已,其他语言编译成 webasm 和编译成 asm.js 没有本质区别, webasm 带来的只有传输和 parse 的提升,没有在 feature 上有什么以前做不到现在能做到的改变……
2016-03-21 00:34:35 +08:00
回复了 livecoding 创建的主题 程序员 WebAssembly 的介绍
@wizardforcel 你还是没搞懂我在说什么。

我说其他语言早就可以编译成 JS ,说的不是 TS/CoffeeScript 这种方案,而是早就有的 emscripten 这种把 LLVM Bytecode 编译成 JS 的方案。

现在的 webasm 实现,其实也是一样用 emscripten 编译成二进制 JS ,和 emscripten 编译成 asm.js 格式的 JS 一模一样,提高的是传输大小和 parse 时间,也就是说如果你只是把几百 K 的 C++项目编译成 JS 来跑的话,没有 webasm 也是一样的(几百 K 的 JS 大小和 parse 时间不成问题),但好几年过去了我没见到这种方案有动摇 JS 地位的可能。

然而如果你要做的是几十 M 的大项目,确实上 webasm 能得到可观的提高,但问题是……你真的会把几十 M 的大项目用 web 方式来做么……再怎么提高,几十 M 的二进制包还是需要很长的时间才能载入的……

所以其实 webasm 一开始出现的时候我就觉得这东西意义不大的。
2016-03-19 23:02:46 +08:00
回复了 livecoding 创建的主题 程序员 WebAssembly 的介绍
@wizardforcel 听到 JS 是除 php 之外坑最多的语言, C++笑了……

大家是不是还没搞懂 WebAssembly 是啥…… WebAssembly 其实是二进制的 JS 而已啊…… JS 要在 JS 引擎上跑需要 JS->ByteCode(类似)->机器码 这样的流程,那直接塞 ByteCode 就又快又小,这就是 WebAssembly 了。

所以这其实是相当于 JVM/.net 一样的东西,但是最后无论是哪个还是最早的那个语言(java/C#)用的人最多。

顺便其实浏览器早就普遍支持 asm.js 了,其他语言早就可以编译成 JS, 最后也没见哪个语言真的动摇了 JS 的地位呢……
2016-03-16 11:41:53 +08:00
回复了 MajestySolor 创建的主题 问与答 flash 的开发团队是不是很烂啊~~
@qq316107934 耍流氓也就在 safari 上耍耍流氓,这种歪理不能解释为什么 flash 在 chrome 和 firefox 上一样很烂。
2016-03-14 00:04:41 +08:00
回复了 xi_lin 创建的主题 iDev 看 Core Animation PG 时的矩阵运算的疑惑
这是计算机图形学基础吧……你的计算机图形学只学过 3*3 矩阵吗?
2016-03-12 00:19:14 +08:00
回复了 jings 创建的主题 Google 不出所料
@wangfengmadking 我倒觉得他说的完全没有道理。
首先说围棋暴力计算就可以这简直是侮辱计算机科学。状态空间为 10^172 怎么暴力?不错这确实是精确的,离散的,死板的输入,但下棋所需要的却是十分模糊的判断决策能力。人类以前能轻易战胜计算机围棋程序靠的是人脑强大的模糊判断能力,现在计算机靠深度学习终于能达到和人类匹敌的模糊判断能力了,这能一样吗?
然后举出对计算机来说困难的事情(认人,辨别物品,走路,开车,打球(?)……),这些事情是什么?比如所谓人类视觉的原理,不过就是:
特征提取->模糊判断->决策生成
人类能高效高质完成决策,是因为这些地方做得都很好,然而其实对于计算机来说,第一步早就有了(很多特诊提取算法),第三步只是单纯输出结果,困难的就是第二步,而这一步现在已经取得了很好的进步( Google photo 认人, Boston Dynamics 的机器人),而如果 AlphaGo 在模糊判断上能为计算机带来从以前渣渣围棋软件到 AlphaGo 这种程度的进步的话,那这些所谓模糊多变的场景算得了什么呢……
1 ... 9  10  11  12  13  14  15  16  17  18 ... 25  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3926 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 30ms · UTC 04:16 · PVG 12:16 · LAX 21:16 · JFK 00:16
Developed with CodeLauncher
♥ Do have faith in what you're doing.