被 JVM 困住了,厌倦了 Java...该去哪里?

发布于 2024-08-05 22:17:46 字数 1431 浏览 12 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(11

太阳公公是暖光 2024-08-12 22:17:47

你考虑过 Groovy 吗?我不认为它的功能与 Scala/Clojure 一样,但它肯定比 Java** 功能强大得多。一般来说,在 Groovy 中完成相同的工作只需使用 Java 中大约 50% 的代码。

这是因为 Groovy 在语法上与 Java 类似,并提供对 JDK 库的无缝访问,但添加了大量语言功能(闭包、元编程、属性)和动态类型,消除了几乎所有与 Java 编程相关的样板文件。

** 我的意思是“函数式编程”而不是“正确工作”意义上的函数式

Have you considered Groovy? I don't think it is quite as functional as Scala/Clojure, but it's certainly a lot more functional than Java**. In general, I can get the same work done in Groovy with about 50% of the code it would take me in Java.

This is because Groovy is syntactically similar to Java and provides seamless access to the JDK libraries, but the addition of a lot of language features (closures, meta-programming, properties) and dynamic typing eliminates almost all the boilerplate associated with Java programming.

** I mean functional in the sense of 'functional programming' rather than 'working correctly'

走野 2024-08-12 22:17:47

我将解决您提出的有关 Scala 的观点。

  • IDE 支持

    Scala 不具有 Java 所具有的相同级别或 IDE 支持,或者就这一点而言,F# 与 VS10 应该具有相同的级别或 IDE 支持。

    也就是说,它是 Java 之外对 JVM 最好的(甚至最好的?)IDE 支持之一。现在 NetBeans 已经足够好了,人们一直说 IDEA 仍然更好(传闻)。不过 Eclipse 插件不稳定。

    但是您提到了 3 年的范围,一旦 Scala 2.8 发布,IDE 对 Scala 的支持应该会大大增强,因为它将为 IDE 提供一些编译器支持。目前还没有确定发布日期,但看起来是在接下来的六个月内,也许是三个月内。 Eclipse 插件也将随之更新。

  • 通量单元测试框架

    是的,如果你的意思是它是充满活力的、不断发展的和得到良好支持的,而不是停滞不前和被遗弃的。 ScalaTest、Specs 和 ScalaCheck 是顶级质量框架,它们之间兼容,并且与其他 Java 框架和库(例如 JUnit 和 JMock)兼容。

    事实上,测试框架几乎就是 Scala 的可能性的儿童海报。

    编辑:Scala 在其标准库 (scala.testing.SUnit) 中提供基本的单元测试支持。然而,鉴于已经出现了许多优秀的、受到积极支持的免费替代方案,它已被弃用,并且可能不会成为 Scala 2.8 附带的库的一部分。

  • 性能问题

    我不知道有什么,除了你可能会写出糟糕的代码,就像使用任何其他语言一样。不习惯函数式编程的人经常会做一些效率不高的事情,例如不使用尾递归或连接列表,而 Scala 实现的范式转变揭示了这一点。

    无论如何,您可以像编写 Java 代码一样快地编写 Scala 代码(对于一些即将推出的功能,甚至更快)。而且您可以编写具有功能特性的 Scala 代码,几乎与 Java 代码一样快。

I'll address the points you raised about Scala.

  • IDE support:

    Scala doesn't have the same level or IDE support Java has -- or, for that matter, that F# should have with VS10.

    That said, it has one of the best (maybe even the best?) IDE supports on JVM, outside Java. Right now NetBeans is good enough, and people have consistently said IDEA is still better (hearsay). The Eclipse plugin is unstable though.

    But you mentioned a 3-years range, and the IDE support for Scala should be greatly enhanced once Scala 2.8 is out, as it will provide some compiler-support for IDEs. There's no release date defined, but it looks to be within the next six months, maybe three. And the Eclipse plugin will be updated right along with it.

  • In flux unit testing framework:

    Yes, if you meant it is vibrant, evolving and well supported, instead of stagnant and abandoned. ScalaTest, Specs and ScalaCheck are top quality frameworks, compatible between themselves, and compatible with other Java frameworks and libraries, such as JUnit and JMock.

    The testing frameworks, in fact, are almost a child poster of what is possible with Scala.

    EDIT: Scala has basic unit test support in its standard library (scala.testing.SUnit). However, given that many superior, actively-supported and free alternatives have appeared, this has been deprecated and will likely not be part of the library shipped with Scala 2.8.

  • Performance issues:

    I'm unaware of any, aside from the fact that you can write lousy code, just as with any other language. People not used to functional programming will often do stuff that's not efficient, such as not using tail recursion, or concatenating lists, and the paradigm shift that Scala enables brings that to light.

    At any rate, you can write Scala code as fast as Java code (even faster with some upcoming features). And you can write Scala code with functional features almost as fast as Java code.

乖乖哒 2024-08-12 22:17:47

坦白说,再找一份工作。

如果您在接下来的三年里对自己所做的事情感到不舒服,那么您应该考虑寻找更具吸引力的替代方案。

即使你设法获得一种你喜欢的语言,如果你是一个团队的一员(我猜你是),团队的其他成员可能不喜欢这种语言。如果其他人使用 Java 编写代码,而您使用“填空”编程语言,那么可能会出现问题。

毕竟,情况并没有那么糟糕。

和你的老板谈谈,让他知道你的感受。开始寻找替代方案,并享受一次愉快而专业的“休假”。

您没有理由不能与现任老板保持良好的关系。如果最终他们有一个新的 .net 项目,你可能会回来。也与他们谈论这一点。让你的门敞开。

Quite frankly, get another job.

If you are to spend the next three years feeling uncomfortable on what you're doing, you should consider looking for more attractive alternatives.

Even if you manage to get a language you like, if you are part of a team ( which I guess you are ) the rest of the team might not like that language. If the rest of them code in Java and you in "fill in the blank" programming language, then problems may arise.

It is not that bad after all.

Talk with your boss, let him know how do you feel. Start looking for alternatives and have a nice and professional "leave".

There is no reason why you can't still have a good relationship with your current boss. If eventually they have a new project for .net you may come back. Talk about that also with them. Leave your doors open.

樱&纷飞 2024-08-12 22:17:47

这并不是真正的零和游戏,全部学习!
ps:我投票给Clojure,我觉得它最好玩!

Its not really a zero sum game, learn them all!
ps: i vote for Clojure, i find it the most fun!

少钕鈤記 2024-08-12 22:17:47

您应该认为自己很幸运,可以使用 JVM,因为 JVM 对于替代编程语言比 Java 来说变得越来越流行。

除了 Java 之外,还有 GroovyScalaClojure(JVM 上的 Lisp 方言)、JRuby(JVM 上的 Ruby),Jython(JVM 上的 Python)、Jaskell(JVM 上的 Haskell)、 Fan(在 JVM 和 .NET CLR 上运行)等等,还有一个 < a href="http://ocamljava.x9c.fr/" rel="nofollow noreferrer">OCaml-Java,运行在 JVM 上的 OCaml。

因此,JVM 上的编程语言有很多选择,从纯函数式语言到简单脚本语言和高级 OO 语言。

You should consider yourself lucky that you can use the JVM, because the JVM is becoming more and more popular for alternative programming languages than Java.

Besides Java there's Groovy, Scala, Clojure (a Lisp dialect on the JVM), JRuby (Ruby on the JVM), Jython (Python on the JVM), Jaskell (Haskell on the JVM), Fan (runs on the JVM as well as the .NET CLR) and lots more, and there's also an OCaml-Java, OCaml that runs on the JVM.

So, there's lots of choice in programming languages on the JVM, from purely functional to simple scripting and anvanced OO languages.

海拔太高太耀眼 2024-08-12 22:17:47

对 Scala 和 Clojure 的工具支持可能还不成熟,但正在稳步改进。

既然您喜欢 F#,那么 Scala 很可能是您的最佳选择。我说尝试一下并形成你自己的观点 - 你可能会发现人们抱怨的事情对你来说并不重要,或者是你可以解决的事情。

Tool support for Scala and Clojure may be immature, but it's steadily improving.

Since you like F#, then Scala is most likely your best bet. I say try it out and form your own opinion - you might find that the things people gripe about are things that don't matter to you, or things you can work around.

暖心男生 2024-08-12 22:17:47

不要忘记 jRuby,并注意 IDE 对于非 Java 来说是可选的,

我认为您的情况很好。有多少人获得选择实施语言的许可?由于 JVM 可用的一切都可供您选择,因此环境选择并不是太大的限制。

  • 在不太冗长的语言中,您不需要强大的 IDE 支持
  • 在像 Ruby 这样强大且没有类型声明的语言中,您根本不需要 IDE
  • Scala 是专门为解决 verbose-java-blues 问题而开发的
  • 算你幸运吧你已经准备好三年的工作了:-)
  • Clojure 可能会很有趣,并且提供功能性并发安全设计模式

Don't forget jRuby, and note that an IDE is optional for non-Java

I think you have a great situation. How many people get permission to choose the implementation language? With everything available for the JVM having your environment chosen is not much of a restriction.

  • You won't need great IDE support in the less verbose languages
  • In a language as powerful as Ruby with no type declarations, you don't need an IDE at all
  • Scala was developed specifically to cure the verbose-java-blues
  • Count yourself lucky that you have three years of work lined up :-)
  • Clojure might be fun and provides functional concurrency-safe design patterns
痴意少年 2024-08-12 22:17:47

努普? http://code.google.com/p/noop/(不过是实验性的)

Noop? http://code.google.com/p/noop/ (experimental though)

心头的小情儿 2024-08-12 22:17:47

就 IDE 支持和您遇到的其他疑问而言,Clojure 并不比 Scala 做得更好。对于具有 ML/F# 背景(或者通常具有严格静态类型 FP 语言背景)的人来说,您肯定会发现 Scala 更接近您习惯的语言。

In terms of IDE support and other doubts you're having, Clojure doesn't do any better than Scala. And for a person with ML/F# background (or generally that in strictly, statically typed FP languages), you'll definitely find Scala much closer to what you're used to.

我的黑色迷你裙 2024-08-12 22:17:47

如果您喜欢 ML,您可能会喜欢 CAL,它或多或少适用于 JVM 的 Haskell 98。

它质量高且非常稳定,并且在 Eclipse 上有良好的 IDE 支持,但遗憾的是不再积极开发。

If you like ML you might like CAL which is more-or-less Haskell 98 for the JVM.

It is high quality and very stable, and has good IDE support on Eclipse, but sadly is no longer under active development.

云朵有点甜 2024-08-12 22:17:46

在我看来,Clojure 和 Scala 都没有很好的 IDE 支持,如果这对您来说真的很重要的话。也就是说,这是我可以从阅读和阅读中收集到的内容。经验。

Scala 的优点

  • 比 Clojure 更快得益于更多的静态类型
  • 更接近 ML(语法、类型定向编程)
  • 更大的标准 API strong> (Clojure 的 API 增长非常缓慢,因为他们希望确保在公开之前找到最好的习惯用法。也就是说,Clojure 仍然有半官方的补充 API)
  • 更好的集成实践 使用典型的 Java 工具集(Clojure 仍在做出一些选择,因此在这方面还不太牢固)
  • 比 Clojure 更老(但 Clojure 构建在一个非常古老且经过验证的核心之上: Lisp)
  • 人们说它有机会成为主流,但他们不会对 Clojure 说同样的话

Clojure 的优点

  • 令人难以置信的简单、快速和正确的并发性强>得益于基于MVCC的STM其他并发机制
  • 默认的不变性有助于首先做正确的事情
  • 更稳定的标准API
    • 当情况发生变化时,通常您无需重写任何现有代码
    • (Scala 的集合在 2.8 中再次重制)
    • (我还在某处读到,众所周知,Scala 的 Actors 实现需要重新思考和重写。)
  • 更容易学习(小语言,成为(非常干净的)Lisp)
  • 为您提供通过学习不同的东西来成长的机会
  • Clojure 的性能只会随着时间的推移而变得更好;编译器仍有很好的优化空间
  • Scala 与 Java 的联系感觉比 Clojure 的限制更多(Scala 和 Java 静态类型系统之间的交互)。人们有时会对 Clojure 说同样的话(面向对象的支持不是 1:1 的配合,但对此的支持很快就会变得更好)
  • Rich Hickey 具有做出选择的天赋,使 Clojure 处于拥有技术领先功能的地位,将在接下来的几十年内被其他语言采用。他还具有解释这些内容的天赋。因此,现在就在 Clojure 中使用它们,或者等待几年后在另一种语言中使用它们。 :)

关于分布式并发

如果您的并发需求是分布式的,Clojure 还没有任何功能,除非您在 Terracotta 或类似的东西之上运行它,在这种情况下您将能够使用它的所有并发功能。如果你这样做,你最终将获得比 Scala 的 Actors 更好的分布式并发体验,IMO。

结论

IMO Scala 尝试做所有事情,并且成功地完成了大部分工作。 Clojure 不会尝试同样的事情,但它所关注的内容已经足够多了,而且非常成功,以至于大多数真正了解 Clojure 的人都不想再回到其他领域了。 披露:当然,我个人更喜欢 Clojure。我希望我所写的内容能够保持客观。

In my opinion, both Clojure and Scala don't have great IDE support, if that's really important to you. That said, here's what I can collect from my reading & experience.

Scala's pros

  • Faster than Clojure thanks to more static typing
  • Closer to ML (syntax, type-directed programming)
  • Bigger standard API (Clojure's APIs grow very slowly, because they want to make sure they find the best idioms before making them public. That said, Clojure still has semi-official supplementary APIs)
  • Better integration practices with the typical Java toolset (Clojure is still making some choices, so less firmly established yet on this regard)
  • Older than Clojure (but Clojure is built on top of a very old and proven core: Lisp)
  • People say it has chances to reach mainstream, while they wouldn't say the same about Clojure

Clojure's pros

  • Incredibly easy, fast and right concurrency thanks to MVCC-based STM and other concurrency mechanisms
  • Immutability by default helps doing the right thing first
  • More stable standard API
    • When things change, usually you don't have to rewrite any existing code
    • (Scala's collections are being remade again for 2.8)
    • (I have also read somewhere that it's common knowledge that Scala's Actors implementation needs a rethinking and rewrite.)
  • Easier to learn (small language, being a (very-clean) Lisp)
  • An opportunity for you to grow by learning something different
  • Clojure's performance will only get better with time; there's still room for nice optimizations in the compiler
  • Scala's tying to Java feels more limiting than Clojure's (interactions between Scala's and Java's static type systems). One could sometimes say the same about Clojure (Object-Orientation's support is not a 1:1 fit, but support for this will soon get better)
  • Rich Hickey has a gift for making choices that put Clojure in the position of having technical leading features that will be adopted by other languages in the decades to follow. And he also has a gift for explaining them. So use them today in Clojure, or wait to use them in another language in some number of years. :)

On distributed concurrency

If your concurrency needs are distributed, Clojure doesn't yet have anything for this unless you run it on top of Terracotta or something similar, in which case you'll be able to use all its concurrency features. If you do, you will end up with a better distributed concurrency experience than with Scala's Actors, IMO.

Conclusion

IMO Scala tries to do everything, and succeeds at doing most of it. Clojure doesn't try the same thing, but what it focuses on is more than enough and succeeds so well that most people really knowing Clojure wouldn't want to go back to something else. Disclosure: my personal preference goes, of course, to Clojure. I hope I've been able to be objective in what I wrote.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文