4 ms·

I have a similar experience with Groovy, the "Ruby of Java". I wanted to quickly prototype an app, so I used Groovy. It was very productive, esp since I deal w

I have a similar experience with Groovy, the "Ruby of Java". I wanted to quickly prototype an app, so I used Groovy. It was very productive, esp since I deal with lots of JSON. Over the time, the prototype has grown to be a serious app, and boy I hate refactoring it. Stupid mistakes such as method renaming can be a nightmare. Yes I should have written more unit tests, but my excuse was it's just a prototype.

sgift 9y ago
> Yes I should have written more unit tests, but my excuse was it's just a prototype. Never understood this point "well, you don't need types, you can just write tests for it". IMO you should never have to write tests for something a type system can find for you. Why should I waste time with something which can be found by the compiler?
- zurn 9y ago
  This is the path to formal methods. You will build formally correct programs very slowly, usually too slowly for the world/app domain.
  - bjz_ 9y ago
    This need not be the case forever. It's still an open problem, but the tooling is getting better all the time! For now types+tests are a happy medium. No need to throw the baby out with the water just because 100% correctness is still unfeasible for everyday business problems.
- crdoconnor 9y ago
  I find that strict type systems are good for 'locking down' execution space and sanity checking but they're not effective at cleanly specifying higher level verification even when that's possible. I'd rather use a combination of tests and stricter type checking. There's no sense in being a fundamentalist about either approach.
  - sgift 9y ago
    > I'd rather use a combination of tests and stricter type checking. There's no sense in being a fundamentalist about either approach. Completely agreed. I tend to prefer pragmatic solutions over strict adherence to some methodology. As a sibling comment noted the natural end of specifying everything beforehand would be formal systems, which are usually not worth the effort. On the other hand I don't see "let's just throw everything the compiler could help us with out, because it's a bit more effort" as a sensible strategy.
tigershark 9y ago
For me it's exactly the same. I use groovy to prototype small functionalities for the big Java application that I'm working on, but I will never consider to use it to build a full non toy-size application. I use Python and Ruby for small scripts and I can't really see how people would ever want to use it for big applications. The lack of static types is the problem. For this reason I don't agree with the author when he says that OO is the problem. While loving functional programming I think that a well executed application written in a OO language with static typing is not a nightmare to maintain. You can write code impossible to maintain in Haskell and you can write pretty nice maintainable code in C#. Probably I prefer the nice balance that you can strike with F#, even with the flaws that it has. (Typeclasses anyone?)
- _pmf_ 9y ago
  Kotlin is a nice successor for Groovy; type inferene instead of dynamic typing, but almost as concise.
lmm 9y ago
At least with seamless JVM interop you can gradually migrate the pieces that need to be more solid over to another language, without having to stop the world and rewrite everything. (Protip: use Scala, it combines the expressiveness of Groovy with the safety of Java. It's often seen as Haskell-like, to come back to the article)
vorg 9y ago
> Over the time, the prototype has grown to be a serious app This is your problem, not the lack of tests. When you use Ruby or Apache Groovy to prototype something, it needs rewriting in a statically typed language as soon as it starts growing into something you want to be production quality. Groovy's good for glue code, build scripts, and tests. Don't build actual systems in it.

sgift 9y ago

> Yes I should have written more unit tests, but my excuse was it's just a prototype. Never understood this point "well, you don't need types, you can just write tests for it". IMO you should never have to write tests for something a type system can find for you. Why should I waste time with something which can be found by the compiler?

zurn 9y ago
This is the path to formal methods. You will build formally correct programs very slowly, usually too slowly for the world/app domain.
- bjz_ 9y ago
  This need not be the case forever. It's still an open problem, but the tooling is getting better all the time! For now types+tests are a happy medium. No need to throw the baby out with the water just because 100% correctness is still unfeasible for everyday business problems.
crdoconnor 9y ago
I find that strict type systems are good for 'locking down' execution space and sanity checking but they're not effective at cleanly specifying higher level verification even when that's possible. I'd rather use a combination of tests and stricter type checking. There's no sense in being a fundamentalist about either approach.
- sgift 9y ago
  > I'd rather use a combination of tests and stricter type checking. There's no sense in being a fundamentalist about either approach. Completely agreed. I tend to prefer pragmatic solutions over strict adherence to some methodology. As a sibling comment noted the natural end of specifying everything beforehand would be formal systems, which are usually not worth the effort. On the other hand I don't see "let's just throw everything the compiler could help us with out, because it's a bit more effort" as a sensible strategy.

tigershark 9y ago

For me it's exactly the same. I use groovy to prototype small functionalities for the big Java application that I'm working on, but I will never consider to use it to build a full non toy-size application. I use Python and Ruby for small scripts and I can't really see how people would ever want to use it for big applications. The lack of static types is the problem. For this reason I don't agree with the author when he says that OO is the problem. While loving functional programming I think that a well executed application written in a OO language with static typing is not a nightmare to maintain. You can write code impossible to maintain in Haskell and you can write pretty nice maintainable code in C#. Probably I prefer the nice balance that you can strike with F#, even with the flaws that it has. (Typeclasses anyone?)

_pmf_ 9y ago
Kotlin is a nice successor for Groovy; type inferene instead of dynamic typing, but almost as concise.

lmm 9y ago

At least with seamless JVM interop you can gradually migrate the pieces that need to be more solid over to another language, without having to stop the world and rewrite everything. (Protip: use Scala, it combines the expressiveness of Groovy with the safety of Java. It's often seen as Haskell-like, to come back to the article)

vorg 9y ago

> Over the time, the prototype has grown to be a serious app This is your problem, not the lack of tests. When you use Ruby or Apache Groovy to prototype something, it needs rewriting in a statically typed language as soon as it starts growing into something you want to be production quality. Groovy's good for glue code, build scripts, and tests. Don't build actual systems in it.