6 ms·
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
by xwolfi 6y ago
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.
- cratermoon 6y ago> 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.
- gher-shyu3i 6y agoFor any non-trival program (more than a couple of files/pages long), dynamic and weak typing are a no-go.
- cratermoon 6y agoHow 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?
- gher-shyu3i 6y agoThere 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.
- jjgreen 6y agoTIOBE gives C 14.32% (1) against Rust 0.49% (29), so "strides" might be over-egging the pudding.
- gher-shyu3i 6y agoHistoric vs future trends.
- thrwaeasddsaf 6y agoWhich tools patch C's shortcomings?
- gher-shyu3i 6y agoStatic analysis tools and subsets like MISRA C.
- thrwaeasddsaf 6y agoDo you have a good one in mind? All the open source tools I've tried are MISRAble
- gher-shyu3i 6y agoNope, I haven't been working with C recently.
- kazinator 6y agoIf 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.
- cataphract 6y agoI 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.
- signal11 6y agoA 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.
- closeparen 6y agoHow 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.
- corty 6y agoWriting 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.
- jnwatson 6y agoIn 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.
- zozbot234 6y agoThe 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".
- closeparen 6y agoIf 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.
- jnwatson 6y agoMillions of lines of production Python code do just fine by doing the thing you should have been doing all along: testing.
- deleted 6y ago[deleted]
- canadianfella 6y agoWhat is “a code”?