不如弄个平台夹

虽然用不着不过下载下来看了一下，macOS 上的效果还是很美观的，支持一下 op 。

码就不领了，给更有需要的人吧。

因为 JavaScript 一开始就不是一个正经的语言。传说中的 10 天造出来的语言，能期待有多好的设计。

关于性能问题，我的猜测是，因为 JavaScript 是没有类型的，基于原型链的语言，这就意味着属性访问的实现方法和静态强类型 OOP 语言里面的 devirtualization 有很大的差别了。OOP 语言可以通过各种编译期的优化来消除 devirtualization 里面的性能开销，但是 JavaScript 的语言基准太灵活了，所以无法优化。（只是个人不负责任的猜想）

另外一个问题是`with`本身把变量直接引入到上下文里，也就是说，不需要写变量名就可以直接把关联在这个变量上的无论什么垃圾都调用出来。

Kotlin 里面的`with`并不会把变量关联的属性都暴露在上下文里，因为看函数签名就可以知道了：

```kotlin
inline fun <T, R> with(receiver: T, block: T.() -> R): R
```

receiver 是被捕获的变量，类型为 T ，block 是一个 receiver 函数，在这个函数里面，`this`的类型是 T ，也就是说必须显式指明`this`再访问这个变量所有可能的方法和属性。这种 aliasing 的写法，显然比把不管什么垃圾都倒进作用域安全多了。

话说过来在有 extension 的语言里，本身 scope 函数就可以自己随手造出来，当然了，scope 函数本身也涉及到了虚函数 devirtualization 的问题，如果语言运行时没有专门优化的话，是会造成性能问题的。

所以，并不是说「简化代码」就很好了。

至于「造出来的原因」，大概就跟语言设计历史上的各种其他的离谱的设计一样吧，因为当时的人们还没意识到哪些设计是好的，哪些是坏的。现在回过头看，也只是在马后炮了。

@AOK123 这样呀，话说秋招途径是什么呢，有没有什么专门的网站还是说各大公司会有专门的栏目可以投递或者问询的嘛……

欧洲的话一般是上 indeed 之类的网站找公司然后逐个发 email 问（？ 然后就是学校或者其他地方也会有一些 JD 但是质量不一定多高就是了……

不过也会担心国外的文凭反过来参与秋招，会不会被 HR 刷，比如说觉得文化方面合不来什么的。另外一方面确实也会担心 PLT 这种爱好会不会被认为太不务正业了（

不过之前只考虑到在欧洲找工作的事情，如果说国外文凭在国内也能参与秋招的话感觉也可以试试看，毕竟算是多了一条路子。

欧元区的话德国和低地国家算是待遇最好的一队，其次是法国和北意大利，瑞士那种……虽然收入是很高，但是看看就好了，而且瑞士的生活成本也不是别的国家比得了的。

法国其实也是大厂几乎不会招应届生了，听说是基本上都把业务外包给了外包公司，当然也和法国的工作合同有关，大厂现在不想承担招一个新人的潜在成本了。德国那边如果能读博后直接留公司倒是很好的路径，就是读博又是吃三年低保，还是挺难熬的。

说起来，如果在欧洲这里找到一个在亚洲区域有业务的公司，然后想办法外派到亚洲或者中国，不知道这个想法怎么样呢。从 op 的角度讲感觉这个大概是最理想的情况？以前倒是经常跟朋友聊的时候会开玩笑这么说，倒也从没这么考虑过。

就是感觉这样的机会大概真的很难找到了……

如果是开源+自行部署，那还是可以的。
小程序就算了…

op 能够保证通过一定强度的自学补足之前的短板，然后做个比较能吸引人的个人项目吗。

但是如果要这么做的话，这些个人项目就要有能拿得出的亮点了……感觉不是很容易的事情。而且对个人的自制力的要求也很强。

我觉得如果对编码和计算机课程生疏了的情况下，快速地复习一下基本的知识点就去找一个工作确实是比较可取的方案，毕竟对 op 来说当务之急可能是让自己摆脱懈怠状态，尽快熟悉工程上的那些实践…这样的话之后也可以慢慢找回状态，一点点积累经验，再去寻找有没有更好的机会了。

加油，祝好运。

我觉得，大部分人眼里的「润」，是为了去过上更好的生活，而不是「我恨这个地方所以让我去做很差的活也心甘情愿」。

这就好像，如果有人问「为什么不考虑当难民拿国籍」，大部分人都会觉得很荒谬吧。

虽然感觉很多人都在嘲讽 op ，但是编程这种事情确实开头是挺难的吧。

我以前自学的时候光是 python 就学了 3 次，然后没一次坚持下来的。

加油吧。

………这种关键词一般前后都要加空格的吧

可以从简单的库开始。

举个不恰当的例子，比如说 compiler ，要实现一个复杂语言的很复杂吧，但是简单的，LL(1)的文法解析，手写可能有点复杂，但用生成器的话基本上大家都会，一个只有 int 和最简单几个语言结构的，大概就是本科生大作业的程度。
那么，在这个基础上，就可以观察一下自己想要做什么方面的扩充，然后去针对性地学习和扩展功能，比如说，更多的基本数据类型、结构体、OOP 、类型检查、编译到特定的机器上，之类的。

像是数据库或者 pdf 库之类的，大概也是类似的内容吧。

而且如果把功能拆分开来然后逐个审视的话，op 也许会发现，其中有许多功能已经有别人做过了，比如说对命令行参数的解析，甚至连 pdf 解析这件事本身也是别人做过的。

那么就可以问一下自己，实现这个项目的目的是什么呢，如果是为了短平快，那么自然可以别的类库都用上，如果是为了学习，就可以自己去寻找各种材料，比如说 pdf 的 spec 或者一些简单的类似项目的代码，来参考学习。

这样的话，就可以从简单的开始，一点一点把项目往复杂里做，也可以先依赖第三方库，在自己写出了自己的版本后把这个库给替代了。

我觉得最重要的大概是两个能力吧，一个是「解决问题的能力」，看 op 的介绍，在这方面应该没有问题。那么第二个能力，就是，组合和拆分，也就是说，把一个复杂的问题拆分成许多小问题，再把小问题拆分成更具体的任务…之类的，把不同的知识点组合起来，然后形成一个可以去做的项目，这样的能力。

赋值语句长这样，感觉以后很难支持数据结构了

自从知道 b 站在热点社会话题（疫情、乌克兰、外国科技、资本家）上的态度后，就不再用了。

看到 lz 说 ICC 就觉得没什么好说的了。伪造工作经验把自己的 cv 给弄脏，值得吗。

毕业了还在学校里反复横跳，首先像样点的大学都不可能招你进去重复读，这种身份在职业市场上的价值可想而知。

还是为了那个印着星条旗的身份证，不管是过着多低贱的生活都是值得的？

这种纯业务 CRUD 的东西没什么开源的价值，不如找外包给个报价。

对猎巫行为感到十分反感。

个人的看法，对时区之类的细节，在 prototyping 的时候不会去特地考虑，毕竟首要任务是弄个 demo 出来。

但是到了 production 的阶段，这些细节都是需要解决的吧。除非在写的是应付学校的作业。

把.Net Framework 时代的东西称为「新的第三方不稳定 API 」也实在太典了。

说到设计模式的话……想到了小学时候的平方差公式，不知道这个比喻恰当不恰当。

大概是，在课本上会讲到，但是其实也不是多么复杂的知识，也许很多人在学到这个知识点之前，就已经自己摸索出来了。

但是反过来说，也不会有人整天写书本、课程或者是开会来教授「平方差公式背后隐藏了什么精神」之类的东西吧？

我对设计模式的理解大抵上也差不多……首先这东西在某些特定的场景是有用的，但是并不是什么绝对真理一样的东西，反过来说，不同人也可以通过自己的实践和学习形成或多或少的属于自己的感悟。

但是如果有人整天在吹「 Java 编程思想」、「 PHP 设计模式」之类的东西……还是离得远远的吧。

顺便提一下，有一些设计模式的存在，是为了解决在语言中缺少的语法结构而出现的。

比如说 Visitor 模式之于 Pattern Matching 。在 Kotlin 这种命令式语言里面不存在 PM ，所以只能用 Visitor 来模拟。

比如说 Strategy 模式之于 Lambda 和 HOF ，所以这种模式在 Java8 之后就没什么价值了。

比起死记硬背设计模式，不如尝试理解一下这些模式是怎么来的。

这背后涉及到的，Language Design Engineering ，还有 Functional Programming 里面的抽象和组合的概念，也许可以获得更多有趣的收获。

能做新项目最好还是尽量争取吧。虽然按照外包的尿性，既然招进来是维护 legacy ，那么应该不太可能转新项目。

不要担心进新项目各种不会，op 换个思路考虑一下，如果继续维护 legacy ，那么几年后再转就更难了吧，毕竟到时候人家对你的要求更加水涨船高，如果现在 op 都觉得困难，那么几年后人家提出的要求，op 又该怎么解决呢。到了那种时候，legacy 的经验就是纯粹的负经验了。

而且说难听点，十年的老项目，还没有 spring ，估计也不会有多好的编程习惯和良好的架构或者约定。

做实习或者第一个项目，用人单位本身就不会对你的工作经验有太大的期待，Java 基础如果够扎实的话，其实就足够了。剩下的，都是边做边学慢慢积累。