V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  secondwtq  ›  全部回复第 61 页 / 共 123 页
回复总数  2447
1 ... 57  58  59  60  61  62  63  64  65  66 ... 123  
2020-02-16 18:33:19 +08:00
回复了 laike9m 创建的主题 Python 《捕蛇者说》Ep 11,聊聊木兰编程语言
@laike9m 谢谢!
2020-02-16 04:08:36 +08:00
回复了 ElderBlood 创建的主题 MacBook Pro 感觉可以把 MacBook Pro 扔了...
MBP 和黑苹果 PC 不是一个定位。尝试用一个去“替代”另一个是不合适的
楼主估计就是需要黑苹果 PC,但是买了 MBP 的那种

苹果自身的问题在于,垃圾桶出来就意味着整个产品线不再有也不再可能有和传统 PC 对位的产品,黑苹果才有市场
2020-02-14 19:21:31 +08:00
回复了 skies457 创建的主题 程序员 有没有这样一种语言
来一点点枚举楼主这个需求的问题:

* “像 JavaScript 一样灵活” —— “灵活”无法定义。如果说能写什么程序的话,那么任何一个图灵完全并且有正常的 C FFI 的语言都足够灵活( https://v2ex.com/t/604915#r_7962546 ),只是 JavaScript 作为没有标准的 FFI 的语言,灵活性很值得怀疑。如果“灵活”是指“同样的程序可以有多少种写法”的话,不同语言由于语言特性的不同,会有不同的角度,比如 JavaScript 的 prototype 很灵活,汇编的内存操作也很灵活。单单“灵活”是什么也说明不了的,既然楼主说了“像 JavaScript 一样灵活”,那楼主要的就只能是 JavaScript。

* “生态丰富” —— 满足 V 站定义的“生态丰富”的语言(假设楼主说的是通用编程语言,并且这里不算 Scala、TypeScript 这种作弊的),用手指+脚趾能数出来,这一上来就大大限制了候选集合。

* “Pythonic 式的简单易上手” —— 这个“Pythonic”又直接把目标锁在了 Python 上——因为“Pythonic”就是指“Python 的特征”,或“根据 Python 所总结出的特征”。从比较的角度讲,编程语言就是这样一个思路的集合,如果以“Pythonic”指导设计语言的话,最后出来的就只是另一个 Python。
再说“简单易上手”,如果说生态尚且可以通过数据量化的话,“简单易上手”是无法定义的,或者说不同的人可能有不同的定义。既然你前面提到了“Pythonic”,那么我只能假设你的“简单易上手”是指“Pythonic”。根据上一段所述,符合“Pythonic”的只有 Python。

* “像 Go 一样并行编程方便快捷” —— Go 在并行编程方面我只能说一般(再说从根上讲这就不是 Go 的设计目标之一),不是很明白这个需求。

* “接近 C/C++ 的性能” —— 能严格满足这一标准的语言只有 C/C++,我在 https://v2ex.com/t/594287#r_7803885 这里说过 C/C++ 在这方面的特殊性。至于“接近”么,“接近”的定义也有很多种,比如在上面那个贴子中有回复提到 OCaml 比 C 快,用 Java 的人会说 Java 的性能不比 C++ 差,哪怕用 Python 的人把 CPython 扔了用 PyPy 之类的也敢这么说( https://news.ycombinator.com/item?id=13748622 ),这个 StackOverflow https://stackoverflow.com/questions/35019918/sum-all-numbers-from-one-to-a-billion-in-haskell 说 Haskell 随手一改比 C++ 还快,而这个 https://stackoverflow.com/questions/17036059/why-does-javascript-appear-to-be-4-times-faster-than-c 上面还说 modern JS engine “may allow performance roughly equal with compiled languages like C.”,

* “Rust 的安全性” —— 这就涉及到前面说的“简单易上手”的定义问题,如果你认为在编程时 reason about lifetime 是正常的事情,那么这条需求是可以与“简单易上手”兼容的。如果你认为编程时不应该时刻 reason about lifetime,并且这件事情会搞得很“复杂”,那这个和“简单易上手”不兼容。
2020-02-14 12:41:18 +08:00
回复了 laike9m 创建的主题 Python 《捕蛇者说》Ep 11,聊聊木兰编程语言
节目中间说 Pattern Matching 的时候提到了“Racket 2012 年的论文”,有具体指哪篇么?
2020-02-14 00:49:58 +08:00
回复了 llj5935 创建的主题 macOS 为什么 Mac 连一个小小的分卷解压都解决不了?
"这么贵的一个电脑,连正常使用都做不到"
Mac 买来并不是让你用的啊 ... 你定位搞错了
2020-02-13 03:23:52 +08:00
回复了 mrcn 创建的主题 C++ 使用 CMake 的 C++交叉编译项目管理第三方库依赖的最佳实践?
看到楼主的 append,来联动一下隔壁 https://v2ex.com/t/643161

我小时候家里订了 2004 年到 07 年的电脑爱好者。当时这个杂志有个论坛,人还不算少,我没事就上去水水(跟 V 站似的),里面有个编程区,没事讨论些 Win32 编程之类的东西。现在看起来平均年龄和 V 站也差不多。
我当时只会 VB6,于是只能喊 666。有次问了个也不知道什么问题(好像是类似“怎么学编程”之类的),被人问了“你不是科班出身的?”,我当时还不知道“科班”是啥意思 ...

楼主链的这个博主 KingsamChen,当时好像是这个区的版主。
后来过了几年,论坛这个东西彻底过气了,再去看原来的站已经没了。没想到人还能找到。
2020-02-13 03:01:48 +08:00
回复了 feifei003 创建的主题 分享发现 发现第三方做的东西一般都比官方要好
这东西本质上是个 integration 问题

第一方和第三方都是同一个东西的不同实现,其实没有本质区别。“第一方比第三方要好”这个 assumption 直接就是错的。

值得一提的区别仅仅有两点:
第一:第一方唯一的优势在 vertical integration 方面。integration 就是我有什么东西,我就加进去,离我近的东西就 integrate 得好一些,离我远的东西就做得差一些或者不做。比如各家手机都会装一套出厂 App,很多出厂 App 是硬件厂商自己做的。vertical integration 就是同一个实体控制的东西 integrate 在一起,原则上效果会更好,比如 Google 和 Apple 的出厂 app 和他们自家手机更配,因为 OS 和硬件都是他们自家的。Pixel 和 Surface 在 vertical integration 方面比第三方方案要好。这方面的极端例子是 Apple。

但是如果大家把自己的东西都 integrate 进来,那最后产品不仅会继承好的东西,还会有坏的东西。比如微博和知乎的官方 App 都 integrate 了它们的广告业务,而 Chrome 也不可避免的 integrate 了 Google 的账户、数据收集和强奸用户的传统。

第二:By definition,第一方只有一个,第三方可以有无穷多个,第三方之间的竞争远比第一方要激烈。

而第一方除了 vertical integration 方面的优势之外,并不保证有其他方面的优势。第一方在非 vertical integration 方面的水平一般只是该第一方的平均水平,术业有专攻,很有可能被市场上其他选手超越。例如:

* 某些第三方有自己独特的优势,比如 Chrome 等 evergreen browser 在 IE11 之前相对于 IE 有速度更快、功能和扩展性更丰富、标准支持更及时的优势,最近本站讨论很多的笔记软件也是百花(shi)齐放,而不是都去用 Apple Note 或 OneNote,因为各家都有自己的特色,vertical integration 反而不是那么重要。
* 某些第三方有强大的自家产品同样可以做到优秀的 vertical integration (比如米家生态和小米手机更配,Office 和 Mac 显然 integrate 的并不好但是依然很多人用,Windows 上某些开发者不用 cmd/PowerShell 而使用 UNIX 的 CLI,而 UNIX 上某些开发者不用 Java 和 PHP 用 .Net Core )。
* 甚至 vertical integration 也不一定是优势——某些是优势,而某些同样可以是劣势。比如上面提到的广告(并不是“第三方没有广告”,而是“你钦定的那个第三方没有广告”)。

楼主的观察更准确的说应该是“发现 vertical integration 并没有绝对的优势”。

因为 personal computing 更倾向于这种“易学易用”的傻逼方案,所以这类问题在 personal computing 上尤其突出。很多 personal computing 上很明显的问题都是同一性质的。
2020-02-13 02:15:57 +08:00
回复了 feifei003 创建的主题 分享发现 发现第三方做的东西一般都比官方要好
拿 Pixel 举例子是不知道 Nexus ?
2020-02-13 02:12:22 +08:00
回复了 hanssx 创建的主题 Linux 请教 Linux Mint 19.3 Cinnamon 桌面顶部美化技术
1. 一般改配置就可以直接修改高度
2. 你想要的是 panel 不要显示 Task Bar,还是要做成 Mac/Ubuntu 里面 Menu Bar 的效果( Ubuntu 之前有和 Mac 差不多的 Menu Bar,但是后来好像没了,和 GNOME 统一了,应该是和 Unity 有关)?前者可以想办法把 Task Bar 这个组件删掉(配置里删掉,如果不行的话代码里删掉),这样就能做到“一个打开的应用同时显示在 dock 和 bar 里面”。
后者稍微麻烦一点,需要类似 #2 的东西,但是这个东西在 Linux 下并不完美(应该也是和 Unity 退潮有关)。

当然我会考虑你把 Task Bar 干掉之后用什么来填充这个空间(绝大多数情况下 Menu Bar 不能完全填满 1366 以上宽度的显示器,#2 那个 GNOME 截图到处都是反生产力的设计,还填不满 1920 屏幕的一半)。可以不填充就留着空白,但是对于我来说这是空间的浪费。如果是 /r/unixporn 的话,可能会考虑显示个网速,音乐播放控制之类的。
哦,我的选择是不用 Dock,因为 Dock 也是反生产力的(尤其在“同一应用的多个实例同时存在”的情况下)。把 Menu Bar,Task Bar 和 Status Bar 放到一起,最大限度节省空间。

3. Workspace Switcher 以文本方式显示,在 tiling 向的 panel 里面比较多见。原因可能是此类 panel 避免了一般客户端软件“把用户当傻逼”的设计思路(但是依然无法避免固有思维的影响,比如绝大多数此类 panel 也并没有啥图形能力)。而在主流偏向于“把用户当傻逼”的软件中做到可能比较难。我没用过 Cinnamon,楼主可能要做好改源码的准备( https://old.reddit.com/r/gnome/comments/a6hjdp/display_workspace_names,对应到 Cinnamon 好像应该是 https://github.com/linuxmint/cinnamon/blob/8fbdd45740e09448f266a567f32037d2497f4752/files/usr/share/cinnamon/applets/workspace-switcher%40cinnamon.org/applet.js#L223 )。

有趣的是,在非 tiling WM 的 panel 中更流行的好像是 graph 形式的显示,比如这个 fvwm 的截图( http://www.xwinman.org/screenshots/fvwm2-taviso.pnghttp://www.xwinman.org/screenshots/fvwm2-karl.jpg ),Cinnamon 和 xfce 也有类似功能。但是好像很少有把两者结合的(上面说了,tiling WM 用的 panel 基本没有图形能力),虽然我用 tiling WM,但是和 tiling WM 的典型目标用户不同,我目前没有给 workspace 设定特定的用途,因此 graph 对我更有用。
2020-02-13 01:32:59 +08:00
回复了 hanssx 创建的主题 Linux 请教 Linux Mint 19.3 Cinnamon 桌面顶部美化技术
@KentY 这个其实不能叫“美化”,因为直接和交互逻辑相关,不是纯样式的东西。
2020-02-11 12:01:36 +08:00
回复了 ety001 创建的主题 远程工作 这并不是远程工作的元年
说起来,今年又是 Linux 桌面元年呢
理论上,这些死宅用的东西在这时候应该是涨价的
2020-02-10 00:23:02 +08:00
回复了 lynn0977 创建的主题 Python 怎么阅读学习源代码
你问对时候了,新鲜出炉的: http://www.yinwang.org/blog-cn/2020/02/05/how-to-read-code
2020-02-10 00:21:40 +08:00
回复了 zfish 创建的主题 程序员 我的笔记系统
Org 有个硬伤文章里面好像没提:只能 PC 用
2020-02-09 23:31:59 +08:00
回复了 mrcn 创建的主题 C++ 使用 CMake 的 C++交叉编译项目管理第三方库依赖的最佳实践?
当然这个并不是绝对的,比如 WebKit 这种项目分成 WTF、WebCore、JavaScriptCore、WebKit 等很多子项目,子项目之间依赖非常紧密(假设把这些项目单独分成几个 repo 的话,某开发者放假回来忘记 pull 其中一个项目,就可能 build 不过),一个 CMake 全都 add_subdirectory 进来就得了。

但是 WebKit 用了 sqlite,这个就用系统的就行。
2020-02-09 23:25:46 +08:00
回复了 mrcn 创建的主题 C++ 使用 CMake 的 C++交叉编译项目管理第三方库依赖的最佳实践?
没用过 Travis CI,但是 CMake 没见过 FetchContent 用得多的。一般 CMake 是假设你系统(或者你的配置里)已经有了现成的依赖,然后再去 find。CMake 是个 build system,不是 package manager。

感觉楼主需要做的是把依赖从 CMake 的 build 中剥离出来单独 build,这样就可以满足“在一个独立的目录中”的条件了。

我倾向于避免把依赖都放在一起 build,因为我用这类工具的经验是如果用得频繁,它们(大多数)都会日常抽风,抽风的最简单解法就是删掉所有 cache 重来,这样我就必须最小化每次 full build 的时间。
亲你好可以的,只是需要多用两年才能解锁哦
2020-02-08 18:50:04 +08:00
回复了 alphatoad 创建的主题 程序员 Haskell 学得我心态爆炸
一般课程应该不会讲到 Monad Transformer 以后
2020-02-08 12:36:10 +08:00
回复了 newghost 创建的主题 Node.js 要设计一个接口,大家觉得哪种看上去舒服点?
老实用 Promise 不好么……
2020-02-08 01:51:21 +08:00
回复了 lzwt806 创建的主题 Linux perl 的 XML::Parser 模块求助
@lzwt806 你直接搜 gelf.h 呗,应该是 libelf 的
1 ... 57  58  59  60  61  62  63  64  65  66 ... 123  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2157 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 38ms · UTC 07:27 · PVG 15:27 · LAX 00:27 · JFK 03:27
Developed with CodeLauncher
♥ Do have faith in what you're doing.