Live data from Hacker News

Rise and fall of JVM languages

blog.frankel.ch

201–210 of 233 posts

Re: Rise and fall of JVM languages

#201
post #111

Earlier quoted context omitted.

Groovy has the best testing framework that I have ever used, Spock. When I write .Net code I really miss it, there is nothing that I found as powerful, even using F#.

What do you miss that's not in F#? Legitimately curious, since F# is the language I miss (or wish to use, I suppose) the most at the moment.

It's the overall experience that is great. Creating a stub or a mock with just: IMyService myService = Stub() // Mock()

Returning something from the stub:

myService.getData() >> data

verifying the returned value without explicit assert:

result == expected (This will show a very informative error in case of mismatch and gives you the ability to see the differences in a diff style window)

Interaction based testing is a breeze with this:

3 * myService.getData()

1 * myOtherService.getData()

And finally the data driven testing is the most natural that I have ever seen. You just need to literally create a table and use the column name in your test or even in your test title. Writing tests becomes a joy with Spock.

In F# I have looked at expecto, fsunit and some other library, but I can't find anything remotely equivalent.

Re: Rise and fall of JVM languages

#202
post #65

The whole getter/setter argument is trite. Project Lombok has been around for years and resolves that issue as well as many more.

Lombok has a lot of issues. First and foremost it won't compile for people who don't bother installing it for their IDE. This greatly hampers OSS collaboration because it raises barriers of entry. I know there is delombok but the whole stuff comes with a lot of drawbacks. Reorganize my project just to delombok my project...whoa...

It is nearly impossible to code any amount of Java without a proper IDE (Eclipse/IDEA). Or at least it isn't a sane decision to do so. Lombok is well supported in both of those IDE, especially for the use case of @Data/@Getter/@Setter. Installing it is just as easy as adding any other dependency (especially in IDEA with it's plugin ecosystem). It really is too bad this isn't just installed as default in the IDE though. Heck, I'd even suggest it be part of the language itself. But for now, we just shrug, install it and get back to coding. =)

Re: Rise and fall of JVM languages

#203

Earlier quoted context omitted.

> Currently, there simply aren't any many contenders in Scala's niche (very powerful statically typed programming languages with a pragmatic bend, i.e. not Haskell). C++ could fit the bill but pushes memory management and Cthulhu on you. That does sound like the niche that Rust is shooting for.

Isn't Rust niche safe low-level (mostly GC-less) programming? I think it is, and the hoops you have to jump through to guarantee that safety are really at odds with what I would call "power".

It often feels high level (iterators and closures and all that), but yes, Rust is definitely designed to give you C++-like control over your memory.

The learning curve is fairly steep, and new Rustaceans do tend to go through a phase of "fighting the borrow checker". But once you get a handle on the ownership rules, I think you very rarely find them blocking you from doing something you actually should be able to do. For example, it is hard to get non-const pointers to two elements of a map at the same time, because the compiler can't prove they're not pointing to the same element, and that would let you violate all the safety rules. But I'm not sure I've heard of anyone running into that limitation in practice. And if you totally absolutely needed to, you could use unsafe code to do it.

The ownership system also gives you a different kind of power, to specify how your API's are supposed to be used, and to have the compiler enforce those rules. If a collection isn't threadsafe, for example, the compiler guarantees that you can't race on it from multiple threads. You can put the container inside a Mutex to let multiple threads use it, but then the Mutex will own the container, and callers can only access it by locking the Mutex. Those are powerful guarantees, and they solve problems that come up in managed/GC'd languages too.

Re: Rise and fall of JVM languages

#204
post #172
post #149

Earlier quoted context omitted.

I've done work for a fair number of banks and insurance companies, and my anecdotal impression is that there is always a java system siphoning data from the cobol systems... Both stay around for the same reason: backwards compatability and a stable api+abi. If you find and old Java system it's often trivial to do changes and recompile. Even a few years old C program is often problematic due to changes in the OS or li…

Js isn't usually compiled at all! And old sites using old js generally still work in modern browsers.

... but modern js almost always have a build step.

But yeah, the fair deal of time I have spent on fixing old web pages was more related to fixing the html and CSS and just minor problems related to js.

Re: Rise and fall of JVM languages

#205

Earlier quoted context omitted.

Ugh, yes, so I did, though that was less about software deployment.

None of these examples are especially illuminating here. In my opinion, two things really exhibit this "code over the network" nature; the class URLClassloader that's been in Java forever and the JVM SecurityManager system. URLClassLoader will load bytecode from any url; give it a url to a jar at some domain and it'll load it. The JVM security model was intended to let app developers define exactly what code could be…

software agents running on arbitrary machines on the network" never took off, seems kind of foolhardy in hindsight

We call software agents "containers" now and arbitrary machines on the network "cloud" but it is the same thing...

Re: Rise and fall of JVM languages

#206
post #164
post #97

Earlier quoted context omitted.

> it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. You underestimate the amount of COBOL code that is still out there running our daily lives: http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Web...

That is very true - there is a lot of cobol out there. Fortunately, it has a JVM target too. http://documentation.microfocus.com/help/index.jsp?topic=%2F...

And .NET as well.

http://www.coss-solutions.nl/index.php/2013-11-18-13-59-23/n...

It can even target Azure deployments!

Re: Rise and fall of JVM languages

#207

Earlier quoted context omitted.

Isn't Rust niche safe low-level (mostly GC-less) programming? I think it is, and the hoops you have to jump through to guarantee that safety are really at odds with what I would call "power".

It often feels high level (iterators and closures and all that), but yes, Rust is definitely designed to give you C++-like control over your memory. The learning curve is fairly steep, and new Rustaceans do tend to go through a phase of "fighting the borrow checker". But once you get a handle on the ownership rules, I think you very rarely find them blocking you from doing something you actually should be able to do.…

Unless one is trying to do GUI related programming.

Re: Rise and fall of JVM languages

#208
post #161

Earlier quoted context omitted.

I have heard that before. I like(d) Perl. Got me tempted to try Scala.

Then don't. I couldn't think of two languages more different in every way.

They are similar in a way that none of them is readable. At least Perl is writable...

Re: Rise and fall of JVM languages

#209
post #164
post #97

Earlier quoted context omitted.

> it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. You underestimate the amount of COBOL code that is still out there running our daily lives: http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Web...

That is very true - there is a lot of cobol out there. Fortunately, it has a JVM target too. http://documentation.microfocus.com/help/index.jsp?topic=%2F...

Wouldn't the JVM's warmup time make it untenable for most places COBOL is used?

Re: Rise and fall of JVM languages

#210
post #208

Earlier quoted context omitted.

Then don't. I couldn't think of two languages more different in every way.

They are similar in a way that none of them is readable. At least Perl is writable...

I find scala infinitely more readable than java. For starters I do not have to skip pages and pages of boilerplate, unless some genius decided to do 1 to 1 translation of his java code
Post reply on HN