Hacker News Reader

Comment by xwolfi | Hacker News Reader

Groovy is a nightmare. We now reject candidates who advocate for it in production during interviews and we warn those who do say they d never dare there but use for testing.

Who cares if you have to write setters and getters by clicking a button in IntelliJ, or have to explicit your types rather than ask every subsequent readers to use their brain as a type inference compiler.

Typing clear code isn't a problem Groovy should have solved by making it all implicit, at the cost of having non compiled production code. A code should never fail at runtime because you made a function name typo that it couldnt tell you about any other time for free.

View on HN

A lot of this also applies to other interpreted languages widely used in production, such as Ruby, Python and Clojure.

You don’t like interpreted languages in production, fine. But rejecting candidates who think differently from you just creates a monoculture and reduces the chance that you learn anything new, beyond reinforcing your own convictions.

Millions of lines of production Python code do just fine by doing the thing you should have been doing all along: testing.

How rational this is depends on your testing culture. With a comprehensive test suite, the guarantees offered by a compiler are not very important. The software goes through all its runtime paces before production anyway.

If you’re not going to write any tests, then obviously compile time is a crucial line of defense.

Most shops will be somewhere in the middle where compiler guarantees offer a real but marginal benefit, to be weighed against other tradeoffs.

Writing tests instead of utilizing the compiler is wasted time and effort. And it is one of the worst kinds of code duplication, because you are reimplementing all the type-checking, bounds-checking, etc. Usually badly, buggy and again and again. And since usually the test suite doesn't have tests for the tests, you will only notice if something breaks in the most inopportune occasion possible.

In unit testing for dynamically typed languages, very rarely do you make explicit type checks. The type checking naturally falls out of testing for correct behavior.

The "tests for the tests" is code coverage.

The point is not "let's just not write any tests". With a compiler that offers meaningful guarantees, you can write more worthwhile tests than "does this function always take/return integers".

If you’re passing or returning values of the wrong type, it’s going to blow up one of your tests. Asserting on a value implicitly asserts its type. Passing a value and not getting a runtime error for your trouble, pretty strongly indicates that it’s the right type.

> A code should never fail at runtime because you made a function name typo that it couldnt tell you about any other time for free.

So you also reject all dynamic and weakly typed languages? No JavaScript, Objective-C, PHP, Python, Ruby, Lisp, or Tcl? No type coercion at runtime?

> at the cost of having non compiled production code

Groovy can be compiled to the same bytecode as Java.

For any non-trival program (more than a couple of files/pages long), dynamic and weak typing are a no-go.

How strongly typed is C? Are non-trivial programs in C a no-go? Would a LISP program more than a couple of pages long be forbidden?

There are toolings that patch C's shortcomings, and there's a reason better typed languages (e.g. Rust) are making strides in C's domain.

TIOBE gives C 14.32% (1) against Rust 0.49% (29), so "strides" might be over-egging the pudding.

Historic vs future trends.

Which tools patch C's shortcomings?

Static analysis tools and subsets like MISRA C.

Do you have a good one in mind? All the open source tools I've tried are MISRAble

Nope, I haven't been working with C recently.

If the language doesn't help you with a function name typo, that's crap dynamic. Not only is that not a feature or benefit of dynamic, but it fuels unfair strawman arguments against dynamic.

Here is something I made largely for my own use:

  This is the TXR Lisp interactive listener of TXR 257.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  TXR is enteric coated to release over 24 hours of lasting relief.
  1> (file-put-string "test.tl" "(foo (cons a))")
  t
  2> (compile-file "test.tl")
  * test.tl:1: warning: cons: too few arguments: needs 2, given 1
  * test.tl:1: warning: unbound variable a
  * test.tl:1: warning: unbound function foo
  * expr-2:1: variable a is not defined

That's still a strawman; it only scratches the surface of what can be diagnosed.

I see where you're coming from, having used Groovy for a few years (in Grails, mostly) but I think you're also overstating your case.

Groovy is very quirky, and it's good at turning compile errors into runtime errors (@CompileStatic negates many of its advantages like multiple dispatch) and making IDE refactoring less effective. But the again, so is Spring. This got better when Java configuration was introduced... and then came Spring Boot, which is a super leaky abstraction, with default configuration that automatically backs off depending on arbitrary conditions (!). And yet people find it valuable, because it reduces boilerplate.

These days, I use Groovy mostly in testing (and Gradle), and it can really make tests more expressive.

Reply on news.ycombinator.com