I had work from home. Never again in my life. Going to the office helped me to split the time in my day and mark when work and when I can rest. Also, when stressed a coworker can help much more easier than from home. My home is my home, my office is my office. Never mix these places.
Stuck in traffic, too many distractions, co-workers complains and politics. If I don't want to work from home I can go to a cafe or travel while work. Never mix socializing with work.
You're right. At the beginning I'm was very happy, but after two months I wanted to go back to the office. I was lucky because nobody forced me a choice.
Gradle scripts are an undocumented superset of Groovy. It's not just Groovy, it's the fact that there's no consistent way to know what settings and defaults come from where.
(And really, why would you know Groovy these days? Is it even used for anything outside of Gradle anymore?)
Groovy is super useful for JSON mapping, objects without boilerplate, spock mock testing, etc. I love it because you can be as loosely typed or as strongly
typed as you want depending on the code you're writing.
I don't see a reason to NOT use groovy in any java project. It makes java so much nicer.
* Easy to read
* Collections tools
* Functional programming with closure
* Traits
* Typed or not
* DSL
* 100% compatibility with all jars
* Awesome framework like Grails and the upcoming Micronaut and SpringBoot
* Enterprise software or script, you're welcome.
Groovy is actually an extremely useful language to know. Something approximating bash for java, but with capability to scale up to full application development. Gradle would be one of the less important reasons to learn it imho.
I mean objectively it's not a bad language for its era, I just never found a compelling reason to use Gradle rather than something else. When I started out on the JVM I used Jython for scripting tasks since I already knew Python, and once I started using Scala I used that for, well, everything really.
I don't want to get too deeply into language wars, but Java, Python and Scala all have "killer" features, things they offer that no other language does - you may not agree with them but there are reasons someone might pick that language over every other language in the world. Whereas Gradle just felt like "it's a Python/Ruby/Perl-like language that runs on the JVM" - if there's something Gradle's actually the best at, their communication failed to convey it.
> Whereas Gradle just felt like "it's a Python/Ruby/Perl-like language that runs on the JVM" - if there's something Gradle's actually the best at, their communication failed to convey it
I assume you meant groovy there. But yes, I remember actually posting exactly that view on here several years ago! I felt that if I was going to learn a JVM language, why not invest that effort in something that was more generally applicable or has broader benefits, and kill two birds with one stone? I deep dived into Scala, and looked into Jython, JRuby and other JVM languages. What I came up against every time was that each of those languages seemed to have significant impedance mismatch with the JVM. I found I really wanted something as close to Java as I could get but with a scripting programming style so that I could do quick experimental coding. For me that is where groovy beat everything else. As I used it more I started building larger projects with it because it scales up pretty well. So I often build about 70% of a project in groovy and then do 30% in Java where I want the real static typing (interfaces, domain model, etc.).
This seamless interoperabiity with Java/JVM is a fairly subtle selling point especially since every JVM language will say they do it. It's only when you try to use them in complex projects and see them fall down that you realise that groovy is the only language that is philosophically trying to be close to Java (I'm fairly keen to try Kotlin to see how that holds up on this count).
> This seamless interoperabiity with Java/JVM is a fairly subtle selling point especially since every JVM language will say they do it. It's only when you try to use them in complex projects and see them fall down that you realise that groovy is the only language that is philosophically trying to be close to Java (I'm fairly keen to try Kotlin to see how that holds up on this count).
Interesting - can you say anything more concrete/specific? E.g. with Scala I've gradually drifted away from a Java-like style over the years, but I found it was very possible to write in a close-to-Java style (e.g. using the Java collections rather than Scala ones, using mutable vars and null and subclasses) when that was what I wanted.
You could be talking about Apache Groovy's seamless interoperability with Java 7. It hasn't kept up with Java 8 and lambdas, let alone Java 9 and modules.
It's still far more seamless with java 8 than any other language. I don't care about superficial syntax similarity, that is not really the point. Nicer interoperability with java streams would be good though.
Not really - or, at least, not that simply. When my last organization moved to Gradle, and we had a Gradle ninja go in and migrate all of our build scripts to hundreds of lines of Gradle scripts, I thought the same thing. So I spent a month on-and-off studying and learning base Groovy (fending off coworkers who would pass by my desk and ask, "what are you doing?" "Learning Groovy" "Why are you learning groovy?" "So I can use Gradle" "Why do you have to learn Groovy to use Gradle, Gradle Ninja already did it for you"). I finally got to where I was, if not an expert, at least comfortable with core Groovy. But even then, there was a lot more to Gradle than just "a build script written in Groovy" - there's another learning curve to climb once you've learned Groovy.
The state machine is very near at Design by contract pattern. There are states, preconditions and other stuff. The question now will be "Why developers never use design by contract pattern?" :)
Design by contact is a lot more general. You can have preconditions and postconditions in stateless code. And statelessness is the best way to handle concurrency. When stateful and concurrent, you get to handle outdated requests intelligently and with as little blocking as possible.
I'm happy when solutions for cancer are found. A little less when the way is genetic engineering. From my ignorance I imagine the genetics like a big complex self programming software and the genetic engineering a way to change little variables in a wide enviroment. In other words: Butterlfy effect, you're welcome.
The point of the butterfly effect is that everything you do could be responsible for some massive change in the future. (though the odds are extremely low)
"using this treatment" and "not using this treatment" are about equally likely to cause a butterfly effect.
If applied to an individual person, how does this present any risks of ecological damage? Alternately, does this concentrate control of the food supply into the hands of people who might decide to starve some population out of greed/apathy/prejudice?
Not only. In Italy there is a toy that explain the BCD (Binary coded decimal) with colored tiny balls. http://www.quercettistore.com/prodotti/rami About 30 years ago.. Sorry but this not happen only in Silicon Valley.
