Groovy love

[Rakesh]

First time I heard about Groovy was when Dick got it in the neck for possibly being less than respectful about it on the podcast years ago.

I've been using it for 6 months now and I can honestly say its been a wonderful experience.

If, like me, you were quite content doing Java and thought all this alternative languages debate (mostly Scala) a lot of hot air then Groovy might be the right stepping stone into the wider world.

I'm not going to give a feature by feature list of what's in groovy but I will say that it has bits of other languages so you get a taste of what's involved without too much risk.

The best part has been writing Java, then trying out the pogos, then trying the collection enhancements, then trying gpars for concurrency, etc. All in my own time. And there's LOADS MORE to explore!

One thing I should say, groovy is not grails. For some reason me and Grails do not see eye to eye and initially made me dislike Groovy.

Rakesh

[Ricky Clarkson]

Let me know when int i = "hello"; is rejected by the compiler and I'll look again.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Fabrizio Giudici]

On Sun, 22 Jul 2012 21:41:02 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> Let me know when int i = "hello"; is rejected by the compiler and I'll
> look
> again.

LOL.

My experience is quite the opposite than Rakesh: I tried it a few years
ago and in the end I thought it was ok for some kind of stuff (not for my
mainstream). In the end I found that that kind of stuff is the empty set:
I found always preferable to do with Java. The only thing for which I
still use Groovy a bit is inside Maven, when I have to do something
special that does not deserve to write a specific plugin.



--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Kevin Wright]

The story sounds familiar except for the part about Dick of course, because I experienced it with a different language :)

A much better "plain old" object type, improved collections, and a decent concurrency library will go a long way to making *any* language more pleasant than Java.  I even looked at Groovy myself, a few years back, for these very reasons.

What ultimately turned me off was the performance hit and the dynamic typing (that, and the existence of Scala).  What has your experience been with these in Groovy?

[Cédric Beust ♔]

On Sun, Jul 22, 2012 at 3:06 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

A much better "plain old" object type, improved collections, and a decent concurrency library

No argument about the first point but I strongly disagree with your next two.

I can't think of big holes in the collections (besides closures, which are a language feature, not a library one, so not relevant here).

As for the concurrency library... seriously? java.concurrent.util is not just very powerful, it's very well designed and it's running tens of thousands of high volume web sites today. No other library can claim to come close to this, except maybe .net's.

-- 

Cédric

[Ricky Clarkson]

Something that surprised me when I first looked javac's source code was that they had added a cons list (immutable singly-linked list).  That opened my eyes a little to the world outside j.u.ArrayList and friends.

The fact that Java's collections have lots of optional methods is a flaw, and we all know about the obsolete but not deprecated classes in there.

j.u.c is heaps better, but I'd say it's not 'reached the ground' yet.  Nobody I've interviewed has known that CopyOnWriteArrayList exists, for instance.  Executors has some traction but it's thought of more as a thread pool than any higher abstraction.

Try chaining Futures, for instance, to create a workflow, and you'll end up using listeners etc., which just aren't needed in libs like Akka and Functional Java.  It's a good set of primitives but we want more!

[Russel Winder]

On Sun, 2012-07-22 at 16:41 -0300, Ricky Clarkson wrote:
> Let me know when int i = "hello"; is rejected by the compiler and I'll look
> again.

Clearly you are a static typing sort of person, so stick with static
typed languages. Dynamically typed languages do not obey the same typing
rules as statically typed languages, and nor should they; the whole
point is that statically and dynamically typed languages are different.

int i = 'Hello'

can never be caught as an error at compile time by a dynamically typed
language since all type checking is at run time. Groovy correctly
throws an exception on this line with ClassCastException.

Conversely, tell me when typing works properly in Java.

ArrayList<String> x = new ArrayList<String> ( ) ;

really? Why? This is 201x, surely type inference should be an integral
part of any modern language. And really:

ArrayList<String> x = ArrayList<> ( ) ;

is just no solution at all.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Russel Winder]

On Sun, 2012-07-22 at 16:41 -0300, Ricky Clarkson wrote:

> Let me know when int i = "hello"; is rejected by the compiler and I'll look
> again.

On the other hand, Groovy has taken a foray into static typing:


import groovy.transform.TypeChecked

@TypeChecked
def f ( ) {
int i = 'Hello'
}

leads to a compiler error:


org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
failed:
/home/users/russel/Progs/OddsByLanguage/Groovy/staticTyping.groovy: 5:
[Static type checking] - Cannot assign value of type java.lang.String to
variable of type int
@ line 5, column 11.
int i = 'Hello'
^

1 error

[Ricky Clarkson]

Sure, I generally do stick with static languages.  Groovy was promoted as a step up from Java, though, which until that line of code is rejected, it clearly isn't.  A step sideways, perhaps.

Isn't Groovy adding static typing now?  Will that line be rejected thereafter?

Java's lack of type inference.. sure.  Does Groovy infer types?

[Ricky Clarkson]

Whoops, you added the static typing info while I was replying..

Can that @TypeChecked be added at the class level?  Within a typechecked class can you still use all/most of the Groovy features or is it basically Java within there?  I might grab a copy and play around, thanks for at least the information you've already provided, Russell.

[Russel Winder]

On Sun, 2012-07-22 at 23:06 +0100, Kevin Wright wrote:
> The story sounds familiar except for the part about Dick of course, because
> I experienced it with a different language :)
>
> A much better "plain old" object type, improved collections, and a decent
> concurrency library will go a long way to making *any* language more
> pleasant than Java. I even looked at Groovy myself, a few years back, for
> these very reasons.
>
> What ultimately turned me off was the performance hit and the dynamic
> typing (that, and the existence of Scala). What has your experience been
> with these in Groovy?

I have no intention of trying to convert static type folks to dynamic
languages, there is no point, both sorts of languages are good when the
languages are good. As to when to use each sort of language, that is a
moot point.

What I wanted to point out about Groovy is that Groovy 2 has taken
forays into:

1. Static typing using the @TypeChecked AST transform.

2. Static compilation with the @Compile Static AST transform.

Whilst there is still some work to be done to make it brilliant, it is
already very good. This means I can write Groovy code and get Java
performance – by judicious application of appropriate transforms on a
basically dynamically typed system.

Groovy is thus no longer just a dynamically typed, dynamically bound
language, it is a mix of static and dynamic. Whether this makes is an
warty ugly hybrid or an indication of future languages on the JVM is
definitely a moot point. Personally I think Groovy is evolving to be the
mainstream JVM language, but no doubt I will be seen as biased. Which is
fair enough.

As for concurrency GPars builds on java.util.concurrent to provide
actors, dataflow, CSP, agents, STM, etc.

As for UI, Groovy is going strong. With Swing giving way to JavaFX,
SwingBuilder gives way to GroovyFX. I think it was right for JavaFX2 to
be a Java API and not mandate a specific declarative language for
describing UIs. GroovyFX neatly fills the gap for people who prefer
something with less overhead than Java programming.

No matter what else happens with Java, Scala, JRuby, Clojure, Kotlin,
Ceylon, Fantom, etc. I suspect Groovy will be a large part of the JVM
milieu for a long time yet.

[Russel Winder]

On Mon, 2012-07-23 at 06:34 -0300, Ricky Clarkson wrote:
> Sure, I generally do stick with static languages. Groovy was promoted as a
> step up from Java, though, which until that line of code is rejected, it
> clearly isn't. A step sideways, perhaps.

Early (i.e. late 2003, early 2004) Groovy marketing was dire, overhyped
just doesn't do it justice.

Until Groovy 2, Groovy was a dynamic language and so different from
Java, Scala, etc. I agree "step up" was just the wrong marketing angle.

> Isn't Groovy adding static typing now? Will that line be rejected
> thereafter?

Yes. If you use the static typing annotations.

Groovy is now entering a "schizophrenic" period, it is principally a
dynamically typed, dynamically bound language, but is now entering into
the statically typed, statically bound arena. I can now write all my
computational intensive microbenchmarks in pure Groovy and get close to
Java level performance. Annotating Groovy is so much easier than
rewriting the computationally intensive bits in Java.

> Java's lack of type inference.. sure. Does Groovy infer types?

Not really, in the Scala sense, but the SpringSource/VMWare workers are
doing a lot on all this, so in the future the answer may be very much so
– it is the right thing to be doing.

[Russel Winder]

On Sun, 2012-07-22 at 16:41 -0700, Cédric Beust ♔ wrote:
[…]

> As for the concurrency library... seriously? java.concurrent.util is not
> just very powerful, it's very well designed and it's running tens of
> thousands of high volume web sites today. No other library can claim to
> come close to this, except maybe .net's.

Sadly though it doesn't look like ParallelArray will make it into Java
8. Unless I missed something recently.

java.concurrent.util is showing more and more high-level features as
Doug et al. work them in, but the problem remains that most Java
programmers still think shared-memory multi-threading is the way to code
up parallel algorithms.

Clearly GPars and Akka are trying to provide something at higher levels,
but traction is relatively poor amongst people other than very early
adopters.

Having done some Java training recently, I am depressed by the attitude
of the average Java programmer. All they want to do is fulfil management
requirements, no thought of improving themselves and their knowledge and
expertise. This is in stark contrast to the folks involved with
organizations who are ditching Java in favour of C++/Python or
Scala/Python of which there is a lot happening, hence me getting solid
business doing Python training.

[Kevin Wright]

On 23 July 2012 11:07, Russel Winder <rus...@winder.org.uk> wrote:

On Sun, 2012-07-22 at 16:41 -0700, Cédric Beust ♔ wrote:
[…]

> As for the concurrency library... seriously? java.concurrent.util is not
> just very powerful, it's very well designed and it's running tens of
> thousands of high volume web sites today. No other library can claim to
> come close to this, except maybe .net's.

Sadly though it doesn't look like ParallelArray will make it into Java
8. Unless I missed something recently.

What!  This on top of the Jigsaw fiasco?

I'm thinking that Java 8 won't actually be Java 8.  Based on established naming conventions, a far more appropriate number would be Java 7S

(though I suspect that Apple has already patented the idea of sticking 'S' to the end of an underwhelming yet over-hyped release)

[Cédric Beust ♔]

On Mon, Jul 23, 2012 at 3:07 AM, Russel Winder <rus...@winder.org.uk> wrote:

java.concurrent.util is showing more and more high-level features as
Doug et al. work them in, but the problem remains that most Java
programmers still think shared-memory multi-threading is the way to code
up parallel algorithms.

To be fair, there is nothing running on the JVM today showing that this is wrong. All the alternate solutions fail on one of these criteria while java.concurrent.util meets them all:

• Proven track record of scaling to very high loads and used in many, many very high traffic sites (starting with Google). And by that, I don't just mean that "company X says they are using language Y", which means very little, but that this code actually powers the monumental traffic that these sites support.
  
  
• Performance coming directly from the mutable aspect. A lot of the immutable approaches to concurrency will use, by definition, more memory and generate more garbage collector pressure, which is often the bottle neck in these high load applications.
  
  
• Easy to reason about. Yes, I claim that understanding errors that arise because of multithreaded mutable code is really not that difficult. It's also easy to solve (albeit admittedly harder to solve optimally). Alternatives offered by actors or asynchronous solutions don't have some problems that mutable code has but they certainly have plenty others (starting by the difficulty of tracing fully asynchronous code to create a reproducible test case).
  
  
• Very mature and powerful tools. Eclipse will even show you who holds a lock to what in the stack frame.

java.concurrent.util has set the bar very high and so far, I remain unconvinced that any other technology is even close to being able to perform as well on all these criteria.

-- 

Cédric

[Ricky Clarkson]

"I claim that understanding errors that arise because of multithreaded mutable code is really not that difficult."

My experience is entirely the opposite.  I found it very difficult to work out what the original programmer intended to happen in what order in code like that, to fix problems without introducing new ones.

PropertyChangeListener spaghetti monsters are real.

-- 

Cédric

[Kevin Wright]

I've worked with, and debugged, code written in several different concurrency paradigms:

• Data-flow
• Asynchronous / Futures / Continuation Passing
• Actors
• Software-Transactional memory
• Shared state with locks & mutexes
• Fork-Join

and my experience mirrors Ricky's, shared state is by far the hardest to reason about.

By comparison, STM is probably the easiest to understand, Asynchronous is the best performing, and Actors the most reliable.  Data-flow and fork-join aren't truly general purpose techniques, which makes them hard to categorise in this fashion.

Shared state *can* have a performance benefit, the LMAX disruptor shows this clearly.  But it also demonstrates  the performance benefit of avoiding locks - which can easily harm performance much more than GC pressure.  This is the same reason that the asynchronous model also performs so well, even in the presence of immutable objects.

[Martijn Verburg]

Hi Kevin

> I've worked with, and debugged, code written in several different
> concurrency paradigms:
>
> Data-flow
> Asynchronous / Futures / Continuation Passing
> Actors
> Software-Transactional memory
> Shared state with locks & mutexes
> Fork-Join
>
> and my experience mirrors Ricky's, shared state is by far the hardest to
> reason about.
>
> By comparison, STM is probably the easiest to understand, Asynchronous is
> the best performing, and Actors the most reliable. Data-flow and fork-join
> aren't truly general purpose techniques, which makes them hard to categorise
> in this fashion.
>
> Shared state *can* have a performance benefit, the LMAX disruptor shows this
> clearly.

My understanding is they have a single threaded model, so the shared
state doesn't really impact in their case.

> But it also demonstrates the performance benefit of avoiding
> locks - which can easily harm performance much more than GC pressure. This
> is the same reason that the asynchronous model also performs so well, even
> in the presence of immutable objects.

I like Clojure's approach in that it generally only copies the small
amount of data it needs. That said, if you 'need' to operate
concurrently on all 1,000,000 elements in that data structure then
yo'd best learn about GC tuning :-).

Cheers,
Martijn

[Kevin Wright]

On 23 July 2012 17:54, Martijn Verburg <martijn...@gmail.com> wrote:

Hi Kevin

> But it also demonstrates  the performance benefit of avoiding
> locks - which can easily harm performance much more than GC pressure.  This
> is the same reason that the asynchronous model also performs so well, even
> in the presence of immutable objects.

I like Clojure's approach in that it generally only copies the small
amount of data it needs.  That said, if you 'need' to operate
concurrently on all 1,000,000 elements in that data structure then
yo'd best learn about GC tuning :-).

Oh yes... You can be quite sure of that!

All good clean fun though :)

The alternative is to get one of those nice shiny Azul boxes, they tend to be a tad pricey though.

 

Cheers,
Martijn

[Russel Winder]

On Mon, 2012-07-23 at 08:25 -0700, Cédric Beust ♔ wrote:
[…]

> To be fair, there is nothing running on the JVM today showing that this is
> wrong. All the alternate solutions fail on one of these criteria while
> java.concurrent.util meets them all:

A quick general response, I'll try and do a more detailed one tomorrow.

Do Java programmers manage the stack. No.

Do Java programmers manage the heap. No.

So why do Java programmers try to manage threads?

Threads are infrastructure and should be managed by the runtime system
just as heap and stack are.

[Ricky Clarkson]

That can't happen with shared mutable objects.

[Rakesh]

Hi guys,

just back from holidays sorry if I didn't response sooner.

Ricky:

"Let me know when int i = "hello"; is rejected by the compiler and I'll look again."

Thats such a staggeringly huge, dumb thing to say, I have to assume you are trying to be provocative. But if I was to give it some thought, here's what I would say:

1. That does not say much about you if thats the level of due diligence you are prepared to do before dismissing a technology that many people (some better than you) are saying is worth a look.

2. If you're hoping the compiler will catch errors like that, then I think you have a bigger problem in who you are hiring to write code.

3. As a professional programmer, I thoroughly unit test my code. A piece of code like that won't get far before its caught.

Fabrizio:

"In the end I found that that kind of stuff is the empty set: I found always preferable to do with Java"

Can you elaborate? At the moment I can't think of anything I would ONLY do in Java if I also had Groovy available and could do a mix.

Kevin:

"What ultimately turned me off was the performance hit and the dynamic typing (that, and the existence of Scala).  What has your experience been with these in Groovy?"

That statement has the smell of 'Java is slow' that used to get bandied about years ago. I guess the answer is I don't know yet. I've yet to come across a development team where performance of the code was measured during development time. It usually comes afterwards, which can be too late of course.

I attended a presentation this year on Groovy performance at the CloudFoundry Day and the message was with constant improvements in the JVM and the new static checking, you are almost the same as Java.

My gut feel though is that unless you are already measuring your app in terms of tsp then its likely to be fast enough. Even if it isn't, once you isolated the critical parts, rewrite that part in Java. I just think the people bitten by this is small.

Cedric:

"java.concurrent.util is not just very powerful, it's very well designed and it's running tens of thousands of high volume web sites today"

I'm sure it is. However, as Russell and Ricky point out, is does feel as though its too low level.

Over the past week I've been reading up on GPars which is an abstraction layer on top of the concurrency libraries and its definitely way easier to work with and feels at the right abstraction level, especially in Groovy (in Java, it still seems verbose because of the lack of closures and the extra syntax).

I think, to get philosophical for a moment, that software development is a journey. Its also very unique to the individual as well. The journey I am on may well lead me to the promised land known as Scala but I do not feel I am ready quite yet and still have to pay my dues, learn more lessons out in the wild with Groovy. Its like the levels you have to pass through on the way to enlightenment. There's no point saying to people 'just use Scala' as they have to worked their way there. Over the years I've heard Dick talk about Java then he started playing with Python and then he moved to Scala.

Like I said, Groovy feels like a door opening onto a wider world. It has enough bits of other languages that I could well get distracted by:

Functional programming and end up in Haskell land or more likely, Clojure land.

Or maybe the dynamism gets into my blood and I end up moving to Ruby.

We all know people in these camps and it would be foolish to say there is something wrong with their choices.

Also, one last think I want to mention. Groovy says it tries to bring the 'fun' back into programming. I know see what they mean. I actually do get that buzz from writing something elegant that required me to have mastered some previously unknown area.

Rakesh

--

[Fabrizio Giudici]

On Sun, 29 Jul 2012 17:51:53 +0200, Rakesh <rakesh.m...@gmail.com>
wrote:

> Fabrizio:
>
> "In the end I found that that kind of stuff is the empty set: I found
> always preferable to do with Java"
>
> Can you elaborate? At the moment I can't think of anything I would ONLY
> do
> in Java if I also had Groovy available and could do a mix.

There's not much to elaborate: it's pretty much a matter of personal
taste, in particular how much one is biased towards static or dynamic.

[Ricky Clarkson]

Thanks for the ad hominem, this list was short of that.

The example is simply a reduction of what real cases often boil down to.  If I decide to change Point to Dimension throughout my code I *want* my compiler, not my users, to tell me when I missed a case.  I'm not seriously suggesting that the example I gave itself is the real problem, it's just the shortest way to demonstrate it that I know of.

I find it insane that a language lets me add type annotations as if I were writing in a typed language, and then does nothing with them until runtime.  That was actually the subject of early Groovy hype, with lines like "It's statically typed at runtime!".  I can't find quotes now, that stuff has validly disappeared from the Internet.

" 3. As a professional programmer, I thoroughly unit test my code. A piece of code like that won't get far before its caught. "

But is every piece of code you have to maintain thoroughly unit tested?  I expect that others don't do the same as you in all cases.  Do your unit tests always catch everything a type checker would?  Perhaps so, but armed with a type checker you can write in different ways that help the type checker catch more errors and without the repetitive boilerplate that unit tests can be.

[Rakesh]

Ricky,

firstly I did think I may have been a bit harsh in tone and sorry about that.

Secondly, your points are from the perspective of static programmer *thinking* what it must be like to use a dynamic language.

I suggest you give it a try and then you might find that compiler help isn't all that important in the end.

Personally though, I don't care about being able to not define types. I actually put them in if its not obvious because I think its cleaner and more readable.

Unit testing, actually test driving (TDD) every piece of code I write is something I aim for. Do I always manage it? Of course not, and its bitten every time with bugs!!! I'm getting better though.

Rakesh

[Ricky Clarkson]

I used dynamic typing exclusively from 1986 to 1997, and I've generally used static typing since but I've always had my hand in dynamic languages too.  I appreciate them and know that there are things that you can do there that are tricky in a static environment.  (define (f x) (f f x)) doesn't translate to any static language I know of (requires infinite types) but Scheme handles it without blinking.  Python's readability is amazing and worth taking inspiration from no matter what type system one implements.  Perl's syntactic flexibility is worth, erm, learning from.  Erlang's tuple-matching is a lot like using types pre Java 5.  JavaScript's prototype model shows us that OO isn't necessarily about classes, Common Lisp's CLOS shows that there can validly be more than one 'this' in a method call.

However, none of those, not even JavaScript, take an existing static language and clone its grammar but change the semantics, then claim to be an advance over that static language and even source-compatible.

Compiler help *is* that important because that's what I use to help me program.  Instead of adding lots of if statements I add a type.  When I refactor I tend to do it in such a way that if I or my IDE do it wrong, I get a compile error.  That means avoiding reflection, making sure I have warnings enabled for nonsensical calls to methods that take Object as a parameter (.equals, List.contains, etc.), avoiding null or at least using the @NotNull/@Nullable annotations so that I get static warnings about possible NPEs.  It sounds like more effort than it really is, though I confess it's getting harder to do that as I get dragged helplessly towards Java web technologies, which seem to actually prefer reflection over ordinary method calls.  At least the IDEs still provide navigation, but my brain doesn't at that point.

A type system also helps in navigating, because the IDE gets a completely correct picture of the code and can find references, let me navigate between implementations and declarations of methods, provide accurate code completion, etc.  I imagine Groovy gets some or even all of that, but I expect there are holes.

[Reinier Zwitserloot]

Ricky Clarkson's got this, but I just wanted to chime in with a simple observation:

If someone rightfully calls out a disadvantage of your language, retorting with "Real programmers test their code, and that would have caught this", is not going to convince anyone that groovy is a good idea. In fact, it'll turn them off of it. Part of the appeal of any language is its community, and having a blowhard in it is always a bad sign. Duh, yes, we test our code, you don't have to patronize. Duh, yes, if my editor will red-wavy-underline this thing right as I write it, that is vastly superior to having to run a test first to find this issue.

int i = "Hello";

You really can't put it simpler than that: This is one area where java has got the drop on groovy. I understand precisely why it's this way, and it is definitely not at all a comment on the general value of groovy itself, but it is a succint and obvious 'proof' that calling groovy 'a strict upgrade to java' is horsepuckey. It's a different language, which is better for some use cases, worse for others. Bout the same for most.

--

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

[Dale Wijnand]

On Monday, July 30, 2012 12:54:34 AM UTC+2, rakesh mailgroups wrote:

"you might find that compiler help isn't all that important in the end"

There is a research that seems to prove that "unit testing isn't enough,

you need static typing", which is very interesting. Here:

http://evanfarrer.blogspot.it/2012/06/unit-testing-isnt-enough-you-need.html

Dale

[Kevin Wright]

Unit testing *cannot* prove correctness by itself, try this for a thought experiment:

• You have a `divide` method.
• You test it against all possible input: integers, floating points, zeros, negative numbers, very big numbers, very small numbers
• You make sure you have 100% code coverage, that your test is ensuring everything works as expected
• You expose this method as part of your API

Then

• Someone calls it, passing a String as an argument

[Rakesh]

*sigh*

so hoped this thread would not end up where others have gone. Its one of the reasons I tried to keep it personal as I am a pretty typical Java programmer used to static compilation.

I can try and address/challenge points as they get raised. Its NOT because I am an evangelist for Groovy. Its not *my* language.

int i = "hello"

I can't be blamed for silly examples. I realise (now) that its meant to represent a bigger issue about losing compile time checking rather than someone writing silly code.

I am saying, that in practice, this check at not happening at compile time, based on my personal experience, has not been a show stopper. At all.

Unit testing definitely made this a non-issue for me. That may not be the only solution.

I seem to have stumbled into a 'religious' issue here and there's not much I can say to convince you that static compilation hasn't prevented me from being way more productive than before.

Rakesh

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/P1tShNeGVtEJ.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Rakesh]

interesting blog.

I agree strongly with the comment posted:

"If he took the theory as absolute, then sure, but surely there was an "in practice" implication (or it's pretty much a straw man argument).

If the unit tests had previously found and removed 10 bugs, of which the static type checks would have found 8, and they also uncovered another 1 or 2 that unit tests didn't find, then sure, "in practice" unit testing does not moot static typing.

But if the unit tests found & fixed 1,000 bugs, or which the static type checks found only 500, and again "another 1 or 2", then I'd say that "unit tests moot static typing" is, in practice, proven.

Hence reporting "static type checks found 1 or 2 extra bugs" is not sufficient to draw a conclusion as you don't have the other numbers to give context.

And of course, I'd lay bets that there are still bugs in the code that neither the existing unit tests nor the static type checks found.

It's still an interesting study & exercise, but I'd dispute the conclusion drawn (altho I am a fan of type checking and particularly the type inference model in Haskell and other FP languages)."

Rakesh

On 30 July 2012 10:33, Dale Wijnand <dale.w...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/q-A3HxccEmsJ.

[Fabrizio Giudici]

On Mon, 30 Jul 2012 11:51:45 +0200, Rakesh <rakesh.m...@gmail.com>
wrote:

> I am saying, that in practice, this check at not happening at compile
> time,
> based on my personal experience, has not been a show stopper. At all.
>
> Unit testing definitely made this a non-issue for me. That may not be the
> only solution.
>
> I seem to have stumbled into a 'religious' issue here and there's not
> much
> I can say to convince you that static compilation hasn't prevented me
> from
> being way more productive than before.
>

Rakesh, this is not only religious but I think that people have many
points here. Kevin just pointed out that unit testing can't be complete.
It would be complete only if one submitted to any piece of code all the
possible combinations of inputs. Of course, this is theory: in practice,
it would suffice to submit all the practical combinations of inputs. This
can be quite large. The fact that you didn't experience problems so far is
not necessarily a strong point: see the inductivist turkey argument by
Russel / Popper. In practice, you might feel strong for a lot of time,
until you get burned. Of course, this is still theory, and in practice I'd
say that personal experience, given that we have a sufficient bunch of
data, is an indicator... for that person.

Let's put this in another way. I think it's a very strong point to say
that without static typing you loose lots of benefits. Now, we can afford
to lose something in change of something more interesting. What's the
benefit you get with Groovy. When I answered in the previous mail
exchange, my point was that with my experience with Groovy I didn't get
much in return: just writing a few less line of code is not enough, and if
it was a very important point to me I'd rather consider alternatives such
as Scala, which allows less lines of code and it's static.

[Kevin Wright]

I definitely see a lot of frustration from people over Java's type system.  Can't say I blame 'em, to be honest.

The only way out is to move to another language.  We had an exodus of people moving to Ruby a while back, but nowadays the favoured route seems to be staying on the platform (that way you get to keep the libraries).  We're even seeing the Rubyists be pulled back into the fold via JRuby.

It's interesting to see the various reactions...

• Those who favoured Groovy are all saying how wonderful dynamic typing is, that static typing is evil and has killed their productivity for years.
  
  
• Those who favoured Clojure are saying the same thing, but also loving their functional programming and homoiconicity.
  
  
• Those who favoured Scala are saying that, actually, it's not static typing that's the problem, it's just the way that Java does it.  Add inference and type classes, then you can get all of the benefits with very little of the pain and boilerplate.  It's also helps if you make the language properly object-oriented, get variance right, and throw in a large dose of functional as well.
  
  
• Haskell users, incidentally, say much the same thing.  Except for the part about object-oriented, because who wants/needs subclassing when you have type classes?

The common message from all of these groups is not that "dynamic typing is better", it's that "Java's implementation of static typing is painful".  Sure, you gain by dropping that with Groovy, but it's not because static typing per-se is a productivity killer.

[Rakesh]

Hi Fabrizio,

To go off tangent for a second, I remember trying to read Lord of the Rings many times in my youth but gave up because I found the writing dull.

I tried again years later and I found that once I got to around page 100, I was then entranced and read them all over a short period of time.

Now here's my (admittedly tenuous) link:

The lack of semi colons, default public modifiers, generated property accessors are just a way in and by themselves probably won't sustain your interest for long.

However, once you start dappling with further features, things start to change immensely.

As for unit testing, I actually use them to design my code:

"now I need my code to do this, so I am going to pass these arguments in and expect this back"

rather than

"if i pass this, then I expect that"

Subtle but important point. Its not about exhaustive input testing.

Rakesh

On 30 July 2012 11:06, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:

[Rakesh]

Hi,

I should say that for me, the statement:

"Those who favoured Groovy are all saying how wonderful dynamic typing is, that static typing is evil and has killed their productivity for years."

Is not true. Here's a statement on the Groovy documentation website about typing:

"I'll finish on some words on when and how to use optional typing. Groovy lets you decide whether you use explicit strong typing, or when you use 'def'.

I've got a rather simple rule of thumb: whenever the code you're writing is going to be used by others as a public API, you should always favor the use of strong typing, it helps making the contract stronger, avoids possible passed arguments type mistakes, gives better documentation, and also helps the IDE with code completion whenever the code is for your use only, like private methods, or when the IDE can easily infer the type, then you're more free to decide when to type or not."

http://groovy.codehaus.org/Groovy+style+and+language+feature+guidelines+for+Java+developers

Rakesh

[fabrizio...@tidalwave.it]

 > I definitely see a lot of frustration from people over Java's type system.  Can't say I blame 'em, to be honest.

 

I'd like to see some numbers here :-) because I don't see any particular frustration at all. I'm not saying it's hassle-free, I'm saying is quite manageable and there's not frustration.

--

f.g.

[Jess Holle]

There are issues.

That said, most developers move on and get a lot done without being overly bothered.

A few just seem to get stuck on every wart -- making mountains out of mole hills (or warts).

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

[Ricky Clarkson]

Java type-system issues:

1. Arrays.asList("foo", "bar") gets the type List<String> when it's the only thing in the expression, but as soon as you pass it to something else the type parameter gets inferred to be Object.

2. No way of saying that an Iterator<String> is an Iterator<Object> even though logically it could be (no covariance or contravariance)

3. Arrays are covariant so the compiler lets you add an invalid item to an array.

4. List<int> doesn't work.  Nothing to do with erasure, as Scala manages it.

5. null inhabits every reference type (like in lots of other mainstream languages).

6. foreach is not open for extension, i.e., it only works with Iterables and arrays.

7. try-with-resources is not open for extension, e.g., it can't be made to work with locks without wrapper objects.

8. Varargs use arrays.  Given the incompatibility between generics and arrays (caused by arrays' covariance) this just seems a mistake.  Again, should be open for extension.

9. No higher kinds.  I can't write Monad in Java because there's no way of saying "this type parameter has a type parameter".  This occasionally results in either code with warnings or duplication.

10. Definite assignment could use a tweak:

final int x;
try {
  x = foo();
} catch (FooException e) {
  x = 5;
}

That doesn't compile because x might have been assigned to twice.  I suppose that's not really the type system but I've typed out that code on my phone now so it's staying!

11. A culture issue rather than strictly a type system issue but the whole Java community seems to have a collective brainfart and start waffling about complexity budgets when they see Enum<E extends Enum<E>>.  Perhaps the type system issue is that Java has no self types so we end up doing that in generics.

[Kevin Wright]

All of that of course, plus the sheer number of times you need to repeat a given type.

• every time you declare AND define a variable
• every time you make a defensive copy of some collection
• every time you create a new collection to accept the transformed output of another collection
• every time you create a property on a POJO
• etc.

And having an IDE generate some of it really doesn't help, this stuff still has to be read.

[Fabrizio Giudici]

On Mon, 30 Jul 2012 14:55:30 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> Java type-system issues:
>
> 1. Arrays.asList("foo", "bar") gets the type List<String> when it's the
> only thing in the expression, but as soon as you pass it to something
> else
> the type parameter gets inferred to be Object.

Ok, I call this minor.

> 2. No way of saying that an Iterator<String> is an Iterator<Object> even
> though logically it could be (no covariance or contravariance)

This is a major pain, but I still have to see an explanation that shows
that covariance in generics doesn't open a serious hole in type safety.

> 3. Arrays are covariant so the compiler lets you add an invalid item to
> an
> array.

Ditto.

> 4. List<int> doesn't work. Nothing to do with erasure, as Scala manages
> it.

Agreed, this is major. But now please tell me how Scala does it :-).

> 5. null inhabits every reference type (like in lots of other mainstream
> languages).

This is complex to debate. In any case, I wouldn't expect anything
different from an industrial, general purpose language from the '90s.

> 6. foreach is not open for extension, i.e., it only works with Iterables
> and arrays.

I call this minor.

> 7. try-with-resources is not open for extension, e.g., it can't be made
> to
> work with locks without wrapper objects.

try-with-resources is completely useless. Lombok's @Cleanup is at least as
robust and more flexible.

> 8. Varargs use arrays. Given the incompatibility between generics and
> arrays (caused by arrays' covariance) this just seems a mistake. Again,
> should be open for extension.

Medium level.

> 9. No higher kinds. I can't write Monad in Java because there's no way
> of
> saying "this type parameter has a type parameter". This occasionally
> results in either code with warnings or duplication.

I call this minor, unless somebody shows me how Monads would make my life
so much better.

[Ricky Clarkson]

What hole do you see in Scala and C# if covariance and contravariance open holes in type safety?  There may well be a problem I don't know of.

As for Monad (or higher kinds in general), I'll try to come up with a motivating example at some point but I'm self-trained to avoid it in Java mainly because the missing feature makes it hard.

[Fabrizio Giudici]

On Mon, 30 Jul 2012 21:07:05 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> What hole do you see in Scala and C# if covariance and contravariance
> open
> holes in type safety? There may well be a problem I don't know of.

In Java if you have a List<String> and you can access it as a
List<Object>, you can put any object inside it:

List<String> ls = new ArrayList<String>();
List<Object> lo = ls; // illegal in Java, suppose it is ok just for now

lo.add(new Date());
String s = ls.get(0); // ClassCastException at runtime.


I don't know about C# and Scala: so somebody please tell me how the
problem above is avoided.

[Kevin Wright]

In one word: Immutability

[Russel Winder]

On Mon, 2012-07-30 at 12:06 +0200, Fabrizio Giudici wrote:
[…]

> not necessarily a strong point: see the inductivist turkey argument by
> Russel / Popper. In practice, you might feel strong for a lot of time,

[…]

Can I assume this is some form of ad hominem argument or personal
invective?

[Fabrizio Giudici]

On Mon, 30 Jul 2012 21:44:51 +0200, Russel Winder <rus...@winder.org.uk>
wrote:

> On Mon, 2012-07-30 at 12:06 +0200, Fabrizio Giudici wrote:
> […]
>> not necessarily a strong point: see the inductivist turkey argument by
>> Russel / Popper. In practice, you might feel strong for a lot of time,
> […]
>
> Can I assume this is some form of ad hominem argument or personal
> invective?

Well, not of course. The fallacious inductivity problem is a very general
one.

[Fabrizio Giudici]

On Mon, 30 Jul 2012 21:21:08 +0200, Kevin Wright
<kev.lee...@gmail.com> wrote:

> In one word: Immutability

In two words: yes and no. Immutability must be pursued as often as
possible, but a general purpose language cannot force it. Lots of
developer around aren't skilled enough to work with immutable-only data.

PS I'm not sure immutability would solve the problem above, but I didn't
think a lot about it.

[Kevin Wright]

The basic idea is that if you "insert" an Apple into a collection of Oranges, then you get back a collection of Fruit.  Both the new collection and the original are immutable, with the original continuing to be a simple collection of Apples.

This nicely sidesteps a *lot* of problems. Not just thread synchronisation, but also things like the Liskov Substitution Principle.

As for allowing mutability then, sure, it can be done.  You simply have to clamp down on your types for the mutable subclass (which is fairly standard practice in polymorphism anyway).  The  mutator methods introduced in the subclass DON'T permit Co- variance, but you're still free to use the inherited methods which will force you back into immutability.

Casting around that is theoretically possible.  Which is why Haskell purists will tell you that casting is unsafe and a lie (tantamount to reflection hacks).  This is also why Scala very purposely made casting so verbose and ugly - you really don't need it if you have immutability and you're using the type system correctly.

[Russel Winder]

On Mon, 2012-07-30 at 21:52 +0100, Kevin Wright wrote:
> The basic idea is that if you "insert" an Apple into a collection of
> Oranges, then you get back a collection of Fruit. Both the new collection
> and the original are immutable, with the original continuing to be a simple
> collection of Apples.

I have to admit that whilst a lot of programming is about transforming
apples to oranges and comparing apples and oranges, the interesting
stuff happens with very big data structures, for example 6GB XML
documents, or 256MB images. You do not deal with these things by value
per se. The solution at the moment is to switch from a shared memory
perspective to a message passing perspective, a return to
object-oriented programming – which most current Java, Scala, Groovy, C
++, Python, Ruby, etc codes that I have seen do not employ. Go and
Groovy/GPars, and others, are trying to alter this. Immutability is
critically important, the question is at what scale. Functional
programming, actors, dataflow, CSP, all have slightly different
architectural views on this. The core issue is surely to remove
shared-memory multi-threading as the main applications programmer tool
of concurrency and parallelism. After all locks are designed exactly to
stop parallelism

[Russel Winder]

On Mon, 2012-07-23 at 15:57 -0300, Ricky Clarkson wrote:
> That can't happen with shared mutable objects.

So don't have shared mutable objects.

Actually is it possible to have a shared mutable object? Aren't objects
supposed to be self-contained state that respond to messages?

[Russel Winder]

On Sun, 2012-07-29 at 13:46 -0300, Ricky Clarkson wrote:
[…]

> I find it insane that a language lets me add type annotations as if I were
> writing in a typed language, and then does nothing with them until runtime.

But the point here is that although you find it insane others do not.
The inference is that you should not use dynamically typed languages,
but that those that want to should be allowed to and not be considered
insane. The moral here is to allow diversity (*) rather than to coerce
uniformity.

> That was actually the subject of early Groovy hype, with lines like "It's
> statically typed at runtime!". I can't find quotes now, that stuff has
> validly disappeared from the Internet.

I have no idea where that one came from, it is wrong. I can imagine
someone saying "It's strongly typed at runtime!"

[…]

(*) I was going to use the term "libertarian" somewhere in here but that
has such different meanings in different places as to be an unusable
term.

[Russel Winder]

On Mon, 2012-07-30 at 12:06 +0200, Fabrizio Giudici wrote:
[…]

> Let's put this in another way. I think it's a very strong point to say
> that without static typing you loose lots of benefits. Now, we can afford
> to lose something in change of something more interesting. What's the
> benefit you get with Groovy. When I answered in the previous mail
> exchange, my point was that with my experience with Groovy I didn't get
> much in return: just writing a few less line of code is not enough, and if
> it was a very important point to me I'd rather consider alternatives such
> as Scala, which allows less lines of code and it's static.

But that is the point statically type and dynamically type are different
with different trade-offs. It is not a question of which one is right
and which one is wrong arbitrarily. Context of use, environment,
purpose, who is doing what, all contribute to which is the right tool
for a given job.

The point about testing is as valid for statically typed systems as for
dynamically typed systems. My expectation is though that unit testing is
a whole lot less important than integration and system testing is. I
think the history of XP and TDD, and the other agile processes is that
most programmers have become too introverted and unit test focused. Dan
North's impetus to move more towards requirements and behaviours is
useful. In the end though the test suites will likely be fundamentally
the same no matter the language be statically or dynamically typed.

[Kirk Pepperdine]

Hi all,


I just installed Mountain Lion on my fairly new MB air and so far the only app I'm having problems with is Mail. I have to restart Mail as it will not connect with anything after opening the lid. I don't know if anyone else has run into this problem. I googled about and a few people are talking about problems with Mail but...

-- Kirk

[Roland Tepp]

Sorry, couldn't resist, but let your class implement Iterable and voila - the foreach is extended!

[Russel Winder]

On Mon, 2012-07-30 at 02:33 -0700, Dale Wijnand wrote:
[…]

> There is a research that seems to prove that "unit testing isn't enough,
> you need static typing", which is very interesting. Here:
> http://evanfarrer.blogspot.it/2012/06/unit-testing-isnt-enough-you-need.html

Thanks for this pointer, I shall be reading the full paper later (mainly
because it seems interesting but also because he used Python), for now I
have just read the blog post.

In the context that this is a masters project not a doctoral project or
a big funded experiment, indications are it is a nice piece of work.
However a number of observations:

— the original 3 points would never be held by anyone who was being
sensible. 1 should always read "detecting all bugs" and 2 and 3 are
just wrong, even from the perspective of a proponent of dynamically
typed languages. So given these as starting focus of the hypothesis, the
outcome of the project was never in doubt!

— the experiment is only one way dynamic → static, to come up with a
strong conclusion there needs to be static → dynamic as well. Also some
more controls are needed to turn a good personal masters thesis into
strong evidence to drive an industry.

— are type errors actually important in the codes under examination?

— the conclusion is phrased well, and is entirely agreeable in the
context of this thesis.

— I have no intention of giving up using both dynamically typed and
statically type languages.

[Russel Winder]

On Mon, 2012-07-30 at 10:41 +0100, Kevin Wright wrote:
> Unit testing *cannot* prove correctness by itself, try this for a thought
> experiment:

This argument is only really useful in this debate if statically typed
codes need no unit tests at all in order to provably correct. Reality is
that all codes need to have unit, integration and system tests, so the
above becomes just a truth for all software development.

[Kevin Wright]

It's worth pointing out that nobody on this list is criticising the value of unit testing, integration testing, load testing, pair programming, code review, documentation, or any other technique demonstrated help with maintainability and catching defects.

But... given that we use all these techniques, and that they're known to be more effective in combination, why then argue that type checking/static analysis is somehow unique in its ability to be superseded by the others?

Nobody would claim that formal code review obviates the benefits of pair programming.  Why, then, is it more acceptable to claim that unit testing can effectively replace static typing?

[Russel Winder]

On Tue, 2012-07-31 at 08:48 +0100, Kevin Wright wrote:
[…]

> But... given that we use all these techniques, and that they're known to be
> more effective in combination, why then argue that type checking/static
> analysis is somehow unique in its ability to be superseded by the others?

I wasn't.

> Nobody would claim that formal code review obviates the benefits of pair
> programming. Why, then, is it more acceptable to claim that unit testing
> can effectively replace static typing?

I didn't.

I am not sure I am up for repeating my argument from earlier emails.
Tweet version (aka tl;dr)

Statically compiled and dynamically compiled languages are different and
have to used with different mind sets.

[Ben Smith-Mannschott]

I had trouble with mail, but of a different sort. It was all like MUST
EAT ALL MEMORY. I suspect it was related to the fact that I had the
account I'm writing this message from connected via IMAP. (This
account contains about 4.3 GB of messages from mailing lists.)

http://twitter.com/bpsm/status/229121141464244224

// Ben

[Ben Smith-Mannschott]

The good new is: Java still works. (Both 1.6.x from Apple and 1.7.x
from Oracle.)

// ben

[Kevin Wright]

The statement

"This argument is only really useful in this debate if statically typed

codes need no unit tests at all in order to provably correct."

led me to believe that you thought I was advocating static analysis IN PLACE of unit tests.  Which would be a silly thing for me to advocate.

My apologies for misunderstanding your intent here.

[Kevin Wright]

Yes/No.  You're still forced to only use it with things that can be Iterables, yet there's a whole category of stuff where foreach makes sense, but can't be represented in this manner.

One of the more obvious examples here is something like a stream of lines coming over a network socket, in which you want the body of the foreach expression to be executed asynchronously for each incoming line (perhaps by dispatching to a thread pool), and for the expression as a whole to be non-blocking.

[Justinas]

Form me IMAP mail accounts works fine, hence the mailbox size is only 2GB.

I want to ask about info panel what by default in dashboard in previous version?
I can't find it to add now. Maybe i'm not searching enough. And actually i'm new to mac:) so bear me:)

[Dale Wijnand]

I would say you could create delegating iterables/iterators for those

types. What would be an alternative would you have preferred?

Dale

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

[Kevin Wright]

On 31 July 2012 07:43, Russel Winder <rus...@winder.org.uk> wrote:

On Mon, 2012-07-30 at 21:52 +0100, Kevin Wright wrote:
> The basic idea is that if you "insert" an Apple into a collection of
> Oranges, then you get back a collection of Fruit.  Both the new collection
> and the original are immutable, with the original continuing to be a simple
> collection of Apples.

I have to admit that whilst a lot of programming is about transforming
apples to oranges and comparing apples and oranges, the interesting
stuff happens with very big data structures, for example 6GB XML
documents, or 256MB images. You do not deal with these things by value
per se.

Sure, you deal with them as immutable structures that you transform into other immutable structures in a declarative fashion. i.e.

val uppernames = names map { _.toUppercase }

*nothing* about that expression suggests that you're working on a value-by-value basis, or prevents it being run entirely in parallel.  Nor does it require message passing or any other concurrency formalism in order to do so.

This is very akin to the style of "programming" that you see in SQL, XSLT, etc.  So it's not a "niche" technique, nor is it a bleeding-edge unproven technique.

 

The solution at the moment is to switch from a shared memory
perspective to a message passing perspective, a return to
object-oriented programming – which most current Java, Scala, Groovy, C
++, Python, Ruby, etc codes that I have seen do not employ.

It's just one of several possible solutions, and is a good fit for a great many problems.  It's also VERY widely employed within Scala via the Akka framework.

 

Go and Groovy/GPars, and others, are trying to alter this. Immutability is
critically important, the question is at what scale. Functional
programming, actors, dataflow, CSP, all have slightly different
architectural views on this.

Again, these are ALL techniques available within Akka.  My personal favourite is to use an asynchronous model akin to node.js (although with multiple threads), which I've found to be blazingly fast (no mailbox overhead) and which also interoperates with actors very cleanly.  So I can mix and match as the architecture demands, switching paradigms effortlessly.

I know that GPars also offers many of the same constructs, but found that Akka has made these things a great deal more composable by taking advantage of Scala's for-comprehensions, and consciously sticking to the Monad contract. (loosely speaking, a monad is anything that supports the map, flatMap and filter operations).  I've also found it far easier, with Akka, to mix different styles in the same codebase.

 

The core issue is surely to remove
shared-memory multi-threading as the main applications programmer tool
of concurrency and parallelism. After all locks are designed exactly to
stop parallelism

100% total and utter agreement.

The next challenge is to then also remove as many blocking operations as possible, and so turn it up to 11 :) 

[Kevin Wright]

Without lambdas, you're a bit limited here.  But with them, I've found scala's approach to work well.

for(x <- xs) { println(x) }

is just syntactic sugar for

xs foreach { x => println(x) }

and

for(x <- xs) yield { x.toUpperCase }

is

xs map { x => x.toUpperCase }

*anything* with the appropriate map/flatMap/filter/foreach method(s) on can be used in a for-comprehension.

(which is why scala doesn't call it a "for loop", because it really isn't)

[Ricky Clarkson]

I can't see the link from covariance/contravariance in collections to XML or images.  I've never seen 6GB of XML as interesting, but I suppose if it contains something interesting.. :)

[Ricky Clarkson]

He should have said [Bertrand] Russell, not Russel.  I don't think it was ad hominem.

[Ricky Clarkson]

Right, which is why List has to be invariant (the only variance supported by Java).  Iterable<String> can safely be a Iterable<Object> logically but not in Java, and Comparator<Object> can safely be a Comparator<String> logically but not in Java.  We have wildcards that can help but they have to be repeated everywhere to be useful and make compiler error messages harder to read.  In the ##java IRC channel I generally advise people struggling with generics to drop wildcards if they can.

The problem you pointed out is exactly the problem that Java arrays have, except at least they throw an exception at runtime.

[Ricky Clarkson]

If you can poke it twice and see a different result the second time it's mutable.

[Ricky Clarkson]

Yes, types are proofs, so it's possible for statically typed code to have no tests and be proven to be correct.  Also, tests can't prove anything correct unless they're exhaustive.  Practically, it's a continuum, so there are more things you need to test in Java than in Haskell, and the compiler does the whole job itself in Agda.  In fact, a couple of days ago I wrote a subtract function in Agda, calls to which *won't compile* if it would yield a negative number.  Not for any real purpose, just trying to expand the old mind.

I'm not even sure if I could write a unit test for that, as the failure cases wouldn't compile.

[Ricky Clarkson]

There you go again with your confusing [to me] extra braces.

for (x <- xs) yield x.toUpperCase // is just as valid. :)

[Dale Wijnand]

Doesn't that mean it must implement scala.collection.generic.FilterMonadic?

(or is it scala.collection.GenTraversableOnce..)

Dale 

[Kevin Wright]

You can implement FilterMonadic if you want, but the compiler doesn't demand that you do.

It's more useful as a marker trait, and to be sure that you've implemented all the methods that you intended to implement.

comprehensions are transformed to map/flatMap/etc. very early on in the compiler, and certainly don't rely on any type information.

[Ricky Clarkson]

LINQ does the same thing for C#, the translation is more like a macro than anything that really knows what a monad is.

[Dale Wijnand]

I fail to see how that is any different to Java's for-each depending on

Iterable. You've replaced depending on a type with adhering to a

implied method signature, or am I missing something?

Dale

[Ricky Clarkson]

Scala could add .map, .flatMap etc., to, say, java.util.Enumeration, via implicit conversions, so then you could write:

for (element <- enumeration) stuff using element

In Java you'll need an explicit wrapper object, i.e., noise.

[Kevin Wright]

More interestingly, you can write:

def lengthyAsyncOp1(): Future[Int] = ...
def lengthyAsyncOp2(): Future[Int] = ...

//this returns instantly

val futureSum = for {

  int1 <- lengthyAsyncOp1()

  int2 <- lengthyAsyncOp2()

} yield {

  int1 + int2

}

... keep doing other stuff ...

//this next line blocks the thread

val answer = Await.result(futureSum)

println("the answer was: " + answer)

That's not something that you can do with an iterator, because map and flatMap represent a much more general concept than just some cursor over a collection.

[Ricky Clarkson]

Back to the Groovy topic, I just found out from a Haskell guy forced into Groovy that it doesn't respect private.  I verified this in the bugtracker but saw conflicting ideas about whether it'll be fixed in the upcoming 2.0 or the more distant 3.0.

He had some lovely things to say about the language.  I must look up 'trainwreck' as applied to programming languages.

[Kevin Wright]

Hang on... What's with all this "could" business?

You know full well that it already does!

[Ricky Clarkson]

Actually, I don't.  I lost track of all the Java compatibility stuff a couple of years ago.  It all sounds good now but I just don't know it.

[Rakesh]

Hi,

I think its very easy to dismiss a language or technology *from afar*, without actually ever trying it. I know I have.

My point about Groovy was, give it a go, the initial ramp up is way lower than say Scala as it integrates so well with Java.

Would I have chosen to stray from Java on my own? Probably not, but I am now glad I did.

All languages will have something on paper that doesn't do it for you, Java has loads for example. But hey, we use it and still get the job done.

This private access situation hasn't been an issue in practice. Why? Because I know the field exits either via the IDE (and that tells me its private) or by looking at the source code (which also says its private). So if I go ahead and use, its because I ignored the signposts.

On 31 July 2012 19:37, Ricky Clarkson <ricky.c...@gmail.com> wrote:

Back to the Groovy topic, I just found out from a Haskell guy forced into Groovy that it doesn't respect private.  I verified this in the bugtracker but saw conflicting ideas about whether it'll be fixed in the upcoming 2.0 or the more distant 3.0.

He had some lovely things to say about the language.  I must look up 'trainwreck' as applied to programming languages.

--

[Reinier Zwitserloot]

On Monday, July 30, 2012 12:24:13 PM UTC+2, rakesh mailgroups wrote:

As for unit testing, I actually use them to design my code:

"now I need my code to do this, so I am going to pass these arguments in and expect this back"

rather than

"if i pass this, then I expect that"

Subtle but important point. Its not about exhaustive input testing.

I'm not sure how far off-topic we've veered here, but if this is a motion to indicate certain programming languages are more productive than others, beware second go-around syndrome. It usually applies to the idea that you feel a newer project is so much better designed than a much older one. Yeah, that makes sense - you know more about the problem domain, etcetera. Same applies to trying to gauge a programming language's productivity when language A is the one you learned to code with and you've now delved into language B. Yeah, it's going to feel like lang B is 'better' somehow. It's not the language; it's you.

Scientific research would require that you eliminate that variable and that's not exactly an easy task.

There is nothing stopping you from writing java code tests-first.

Rakesh

On 30 July 2012 11:06, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:

On Mon, 30 Jul 2012 11:51:45 +0200, Rakesh <rakesh.m...@gmail.com> wrote:

I am saying, that in practice, this check at not happening at compile time,
based on my personal experience, has not been a show stopper. At all.

Unit testing definitely made this a non-issue for me. That may not be the
only solution.

I seem to have stumbled into a 'religious' issue here and there's not much
I can say to convince you that static compilation hasn't prevented me from
being way more productive than before.

Rakesh, this is not only religious but I think that people have many points here. Kevin just pointed out that unit testing can't be complete. It would be complete only if one submitted to any piece of code all the possible combinations of inputs. Of course, this is theory: in practice, it would suffice to submit all the practical combinations of inputs. This can be quite large. The fact that you didn't experience problems so far is not necessarily a strong point: see the inductivist turkey argument by Russel / Popper. In practice, you might feel strong for a lot of time, until you get burned. Of course, this is still theory, and in practice I'd say that personal experience, given that we have a sufficient bunch of data, is an indicator... for that person.

Let's put this in another way. I think it's a very strong point to say that without static typing you loose lots of benefits. Now, we can afford to lose something in change of something more interesting. What's the benefit you get with Groovy. When I answered in the previous mail exchange, my point was that with my experience with Groovy I didn't get much in return: just writing a few less line of code is not enough, and if it was a very important point to me I'd rather consider alternatives such as Scala, which allows less lines of code and it's static.