@28painters 比我强 👍

@bigjie910 厉害，已经摸到门把手了 ：）

@charlie21 这个建议挺有意思，我现在的 Listen(听力) 部分确实也是先听再揭示字幕，但图片/视频本身还是会提供一些语境线索。
你说的“第一遍进一步弱化视觉信息”我之前倒没有认真测试过，我记一下，后面可以做个版本对比看看。

@billytv 如果是长视频的话，目前确实是有很多，但是他们的启动心智很高，你必须要进入长时间的学习环境才能学习，而不是 5 分钟，10 分钟这样的碎片化环境。
听的心智以及长视频太长本来 5-6 分钟的长视频，实际要能吃透可能会花更久的时间，甚至半小时。在听的时候需要不断的重播+跟读，实际消耗的时间会比听视频的时间更长。而启动的成本和心智就偏向于有宽裕的时间才打开。
如果按照句子一句话一句话，或者 2-3 个句子组成的片段来听的话，然后以短视频流的方式，启动心智和所耗费的时间会更少，因为你不想听的时候只需要听完这一句，然后划掉 app 。

@june4 不好意思，给你带来不好的体验。已经重新优化了游客版本，放出了更多可以体验的功能
之前文章写的有点歧义，准确说要完整的体验很多都被收在了注册用户里面，不过目前的话又开放了一批新的功能。
更多的注册用户能体验的功能将会在未来的游客版本陆续推出。

@barnetime bug 已修复，同时放开了更多游客可以体验的功能出来。
确实，做语言学习的现在算是红海了，基本上 vibe coding 第一站就是语言学习😂

@Augi 感谢反馈，这块确实是我现在比较欠缺的地方，之前更多精力都放在功能上，视觉和设计体系基本是自己边做边摸索的。获客这块也还在学习中，感谢支持。

@barnetime 感谢这么详细的分享，和帮忙测出了这个 bug

你说的“缩短单次学习投入”和“自己做的产品自己一定要用”这两点也是我做这个产品的初衷。按句子切分以后启动成本会比较低，通勤、散步的时候都可以直接打开听几句，不需要先进入一整段长视频或者完整课程。

我自己本身也是听力比较菜的那类人 😂，有时候跑完步就会打开听一会儿，做成 App 以后这种碎片时间用起来确实挺方便的。

不过你这个已经能做到每天自己用 1-2 小时真的很厉害，我现在也觉得比继续堆功能更重要的是先把核心 loop 做到真的让人愿意反复回来。

@hellodigua 至少还是有用户的 😂 我现在感觉教育类产品光是获客和留存就已经挺难搞了，付费都还没走到考虑的阶段。

@minibear2021 确实，这句话我表述得有点满了 😂。目前主要精力还是放在 App 上，Web 版是在 App 功能的基础上重新做了布局，也补了一些键盘交互，但毕竟最初的交互逻辑是围绕移动端设计的，所以桌面端的体验和适配确实还有不少问题。

更准确地说，应该是“已经做到了我自己闭门开发能想到的程度”，离真正打磨完整肯定还有距离。现在发出来也是希望让陌生用户实际用一下，把我自己长期使用后已经意识不到的问题暴露出来。

如果方便的话，也很想听听你觉得目前最明显的问题是什么。

@rogwan 可能是因为浏览器操作的原因，web 浏览器的话我建议直接在推荐这样刷，然后字幕出现和关闭可以用键盘 T 和 O 快捷键，手机屏幕的话是底部导航栏的第一个 icon 作为入口。 听力不能跳过的原因是要有反馈，我才能训练推荐算法 根据用户的反馈情况去推送他到底会什么不会什么，而不是随便推

感谢反馈，这个确实是个问题，在 web 上部分图片比较亮的时候文字可读性会变差。我先记下来，可能准备给文字区域加一层渐变/遮罩提高对比度。

@gullitintanni 虽然发这个帖子有一定的推广存在，但是如果把每篇文章串联起来，你会对“一个编程语言是如何开发的？”有比较清晰的认识，也算是一种教程/科普性质的文章。每次文章出现的 Hulo 和标题代的 Hulo 其实可有可无，换成其他语言也是同理，主要是为了浏览器 SEO ， 因为这类项目的关注度和推广难度真的很难做起来。

@vfs 是的，蛋疼就蛋疼在这里，所以 hulo 需要一堆语法糖去实现这个过程，让用户写起来不需要关注平台的封装，Hulo 会将所有复杂性留在标准库里面，而且也不做编译器内的硬编码，所有的转换都在 .hl 文件里面实现

@vfs 其实最直接的理由就是，著名是开源项目 Kubernetes 中 bash 2.4 % + powershell 0.2% > python 0.0% 而 Hulo 存在的意义就是要让 2.6% 变成 Hulo 。不过这可能是目前的幻想 hhhh

@w568w 感谢支持。除了 V2EX 我在 b 站的时候宣传评论区也存在诸多不解。大部分人的第一印象就是 为什么不直接用 python 、js 等脚本语言写什么批处理，就存在这种刻板印象。不过也还好，质疑的声音越多，我就可以试着表达我的想法和告诉他们为什么需要 Hulo 这样的语言，也能带来更多的曝光度。要开发一个跨平台的批处理编译时真的，复杂度太大了。目标语言的语法一坨又一坨 要统一他们只有各种的语法糖（运算符重载、操作 ast 、comptime 条件编译...）。有时候 bash 用户可能没有 bc 要用 awk ，有时候可能只想用 (( )) ，batch 的延迟展开 这些操作 真的蛋疼

@llsquaer Hulo 现在的定位是批处理脚本的编译时，因为 Hulo 的完成度不是很高，对外宣传的还是比较保守。Hulo 现在能够基础的解释，未来还会为对接上 LLVM ，设计出自己的字节码。至于为什么这么做？因为很多项目都是 bash 、powershell 写的，可以实现一个提升器(lifter) 或者说是 反编译器，将这些语法向 hulo 转换，而 hulo 就能成为这些语言的 IR ，那他能够打包成其他语言，甚至提供 runtime 、native 机制。最终成为批处理脚本的 LLVM

@spritecn 每个语法的设计都有考量的，整体上语法是师从 typescript + rust 的。1. 在接口的定义和实现上抄了 rust 的 impl, 分离具体的实现类和接口之间的耦合，这样可以在任何位置实现，比如说 impl findstr for grep, impl grep for findstr ，不同平台命令可以相互实现。2. comptime 这个语法糖他是一个表达式，可以塞在任何地方，所以他和传统的宏还不太一样，他可以耍无赖的放在函数的参数里面，比如说 echo （ true, comptime { ... }） 至于这要做有什么用，就是后面 hulo 会开发的，hulo 的 comptime 可以操作 ast ，但是不同于传统的编程语言 只能操作包裹的子类节点，hulo 的 comptime 能够直接操作父类，也就是说 经过 comptime { ... } 的执行，外层的 echo 可能被替换成 Write-host ,之所以会这样设计 也是为了跨平台的考量。如果是 go, python 的语法糖压根达不到这样的水平。3. hulo 的命令是基础类型，可以对命令进行组合相互实现，例如 use grep = find & findstr 这样的，有点类似 ts 的类型体操，但是 hulo 的机制更加复杂，因为命令有不同的 options 还需要更细粒度的组合，因此 hulo 还参考了 css 的选择器，支持对命令进行更精细化的提取。总的来说，Hulo 的这些语法糖就是为了统一这些平台的语言设计的。

@xgdgsc 这差的很多吧，Hulo 的目标是编译成 Bash 、Powershell 、VBS 、Batch 统一批处理脚本，作为批处理脚本的中间语言，你可以理解成批处理脚本的 LLVM ，然后在写一个提升器，将 Bash 转化成 Hulo ，就可以实现 Hulo 到其他批处理脚本的转换