Re: Lazy primes with Java 8 (was Re: Java 8 Streams and Eratosthenes)
Am 10.06.2013 03:28, schrieb Arved Sandstrom:
On 06/09/2013 08:27 PM, Sebastian wrote:
Am 05.06.2013 22:43, schrieb Arved Sandstrom:
Me I wouldn't re-invent the wheel in this case. Implementing this type
of laziness is not that straightforward.
And why not use interop between JVM languages? This way you leverage the
strengths. I usually have Java as the main language, but for some
functionality in some apps I use Scala. Maintainability goes up, for
starters, as does reliability and speed of development.
It's all ultimately JVM bytecode.
AHS
It's not everyone has a management who sees it this way. In our large
project (we're talking several hundred developers and a really
complicated build process), I don't see anyone advocating more
complexity by adding another compiler and language.
[snip]
private LazyConsList<Integer> sieve(FilterableConsList<Integer> s) {
Integer p = s.head();
return cons(p, () -> sieve(s.tail().filter(x -> x % p != 0)));
}
Now I think that looks pretty neat (and almost exactly like the
corresponding Scala code.)
-- Sebastian
It does look reasonably nice, I must admit. :-) I'll have to return to
Java 8 experiments and I think I'll start with a variant of your code.
If you wish, just send me an email and I'll send you my code
privately as a point of departure. I don't wish to put it on
a public site, however.
[snip]
or architectures that they can't find enough qualified people for. So
long as the entirely new stuff is based on Java I guess the working
assumption - hopelessly naive and ludicrous - is that any Java developer
will get it right away.
That is very often true. And because of that mind-set, often not enough
time is set aside for developers to test new technology in a project
context, build prototypes etc.
I am fortunate enough as a very senior consultant (very senior means
that you can converse about having used punched cards :-)) to mostly
work gigs now where I can dictate architecture, design and
implementation. I also now - where I can - avoid projects that involve
more than one architect/designer (who is also a skilled coder *), 2-3
developers, a great BA, and a good QA/QC person. I've found that a
skilled team this size outperforms a 20-30 person team easily, 9 times
out of 10.
I have also found that small focused groups of up to 8 people can
achieve amazing results when protected from outside interference.
Whenever possible, we try to split up in teams about that size.
Architecture and QA are usually orthogonal to that.
More specifically, what really is the complexity of introducing some
Clojure or Scala compared to requiring that your developers master new
Java APIs?
It's not just the amount of complexity, its also where it lies - just
development, or also build process, configuration management, deployment
infrastructure setup (conventions for IDE settings etc.) If it were just
learning a new language - most developers love to do that.
I've seen considerably more project problems due to imperfect
understanding of JPA 1.x/2.x, or IO/NIO, or web services and WSDLs, or
RMI, or concurrency - all Java - than any problems caused by
implementing logic in a language better suited for it than Java.
Quite true. If you don't know hat you're doing, you're bound to screw up
in any language. With some things, however, it's not just API knowledge.
Concurrency, for example, I believe to be an intrinsically difficult
subject.
AHS
* Not usually the case in my experience. I have no idea what process
anoints a majority of the "architects" out there, but it's not
programming skills.
Do you know Simon Brown's work in progress "Software Architecture for
Developers"? (https://leanpub.com/software-architecture-for-developers)
Among other things it's about how coding is part of architecture, and
what is "just enough" design. Entertaining read.
-- Sebastian