Spring Boot 和 Java EE 是企业级架构，那可以用来写 Minecraft 吗。

@huzhikuizainali 如果是 Java 语境里的「继承」关系，一个接口不能被具体实例化，接口和具体类之间的关系当然不是继承关系而是典型的子类型关系。codehz 的回复应该很清楚了。所以您应该知道前面问题怎么用代码来写了。

而您的直觉也是正确的。

我重新想了一下，或许这里讨论的是那种典型的 class extends 关系的，也就是父类先调用构造器后子类再调用构造器，然后逐个字段填入属性的这套过程。如果只从 Java 的角度很狭义地考虑的话，那么这个过程里面确实和对象有一点关系——调用构造器后会创建一个对象。或许，他想介绍一个子类对象可以被强转为父类的对象。这是我能想到的所有东西了。

但是这个提法显然是有问题而且很含糊不清的。子类型或者继承/派生关系也确实不需要牵扯进来具体的对象的概念。说实话，关于类继承和接口继承，我觉得那两句话里面的对象换成类型，也就「类继承根据一个类型的实现定义了另一个类型的实现」，「接口继承描述了一个类型什么时候能被用来替代另一个类型」，反而更准确一些。不知道是书本翻译的问题还是原书对一些概念的解释不清楚。

Java 的 OOP 和 C#的 OOP 没有本质上的区别，可能和 C++的有点区别就是。

其实也不是不行，如果他有一些重名的类或者属性的话就正好可以用上了（ bushi

话说 Foo 那一行在 C#里面应该写 Foo foo = new (); 吧。

光是看 op 的描述感觉都要长脑袋了。

建议用比较清晰的专业术语来描述一下，比如子类型（ subtyping ），虚函数的派发机制（比如 dynamic dispatch ），还有早期绑定和多态（ polymorphism ）。说不定就没有这些疑惑了。

现在看到这种模糊不清似是而非的语句真是头大。

点子很有趣，但是感觉东西太多了……？

这种 app 的话感觉 less is more 还是很重要的。

C 语言算不算（

有个叫 Tailwind Component 的网站有一些代码片段，不过比较少，属于将就着用的水平。想要做好点的效果还得自己手写。

要不就用 Daisy UI ，但也只是封装了一些 Controls ，像 pricing 列表这种具体的东西得定制。

1. 应聘者的过往经历和技术栈分布是怎样呈现的呢，是真的像刻板印象那样 Java/Spring/Vue/Angular 占多数，还是一些小众技术和框架也有容身之处呢。招聘者的偏好又是什么样的呢？
2. 个人 blog 、个人项目、社交网站和 GitHub 还算加分项吗，还是已经成为标配了。
3. 不知道 op 注册的招聘网站有没有 ATS ，如果可以稍微介绍一下说不定能帮助许多人。

只需以用户的视角发表自己的观点：

指的是其他热心用户每提出一个想法或者建议都会被冷言反讽怼回来。

空格或者小数点分隔的手机号怎么办呢，比如

123 4567 8901
12 345 678 901
123.456.78.901

低代码那么 nb ，可以生成一个 minecraft 项目吗。

生成白板项目也不需要低代码啊，Spring Boot 之类的框架都不缺脚手架，再不成自己手写 gradle 文件都不难，低代码有什么好处？

我很好奇牛逼哄哄的低代码怎么处理类似 Java/Kotlin/Scala 互调用，维护 Actor 模型，还有 Hibernate 接入这些场景。随便说的几个例子，好些都得去 GitHub 的 issue 区去跟进或者自己手动 hack 的，直接写 Java/Kotlin 不比那低代码平台更方便？

如果低代码是「用来构建然后就可以丢了」的，构建一个白板项目并没多复杂，引入这种莫名其妙的第三方平台的潜在风险反而更不可接受吧。

最后，Java 又不是只有面向企业编程。面向企业也不是只有 Spring Boot 。对在校大学生来说 Core Java 和软件设计的基础原理比具体的技术栈重要多了。

低代码平台是指那些连个 for 循环和递归都不好写或者压根写不出来的拖拽控件吗，哪怕企业开发都没法不跟树形结构打交道，依赖低代码的最后都会死得很难看。

以为是捷径，到头来发现死路一条。

至于 ChatGPT 会淘汰程序员，让人想起了打字员的职业。

virtual thread 又不是 coroutine 。

锁神教的教徒们还是会继续上锁，然后把 carrier 干废。

重构吧……恭喜你重新发明了响应式编程。

拿头跟原生支持异步模型的语言比。

看了一下 quarkus 的 blog ，感觉对这个其实没啥太大的兴趣。reactive 的技术栈下，「开很多个线程」并不是一个痛点。

就是不知道 virtual thread 对 reactive 技术栈有没有什么帮助了。感觉还是存疑。

感觉玩不了，渲染有问题，到处都是光污染。

星铁没问题而且很流畅。

编译速度慢很正常啊，得看打包后的镜像的内存 CPU 占用。Native 比 JVM 压根都不是同一个数量级的。

开发环境一般也是不用 native 编译的。

个人喜好是 camelCase 或者 PascalCase ，不过还是觉得造语言的时候 case 是不重要的事情，这个更多是根据社区的习惯来的吧。

比如说一般来说 C++社区也会有一些特定领域和类库会习惯用 PascalCase 。

（然后印象比较深刻的是 OCaml 社区在类名上用 camel 而不是 Pascal ）

女性并不是铁板一块，为了蝇头小利抛弃自己同胞的事情还少见吗。