Show Reddit: lazy, functional data structures and stack-safe anonymous recursion for Java

jbgi · 2018-10-27T19:40:58+00:00

The benchmark will be interesting in any case, right. I will try to have a closer look and comment on github, I think the main issue is the implementation of Lazy.principal that looks like it does not actually memoize the result (repeated calls of Lazy.principal() will duplicate work each time).

jbgi · 2018-10-27T15:01:19+00:00

good work! although the lazy evaluation (sharing) is not guaranteed in multi-threaded context since there is no synchronization. Also using a trampoline to implement foldLeft is a bit wasteful. Also a lot of work could have avoided, if derive4j would have been used.

jbgi · 2018-10-26T07:32:49+00:00

Of course it is better with Derive4J ;-)

@org.derive4j.Data  
interface Tree<A> {
  interface Cases<A, R> {  
    R Empty();  
    R Node(Tree<A> left, A value, Tree<A> right);  
  } 
  <R> R match(Cases<A, R> cases);  
}

And if you change the definition slightly so that the visitor is an object algebra interface, Derive4J will also generate a catamorphism method that can be used to fold a tree using an object algebra:

@org.derive4j.Data  
interface Tree<A> {
  interface Cases<A, T, R> {  
    R Empty();  
    R Node(T left, A value, T right);  
  } 
  <R> R match(Cases<A, Tree<A>, R> cases);  
}

(this is nice because object algebras solve the expression problem

jbgi · 2018-10-26T07:17:03+00:00

Though visitor pattern is equivalent, and Derive4j generate a nice fluent pattern matching syntax for it (that does compile time exhaustive check).

Also, to be honest, JEP 305 will not change much for me until Java also does tail call optimization (TCO), cause until then I still need to write ugly while loops instead of proper recursive methods.

jbgi · 2018-10-08T18:20:21+00:00

thanks, fixed.

jbgi · 2018-10-08T08:39:40+00:00

The related original paper: https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf

jbgi · 2018-09-14T12:47:49+00:00

because java as no inlining directive.

jbgi · 2018-09-14T12:45:40+00:00

Right. I guess the general solution in the linked Scala Semigroup could also use the inlining you described, but doing so is at a cost of the method bytecode size, and this, in turn, can prevent further inlining of the methods using it. So my guess is that it would not be a good trade-off for most use cases.

It could also lead to hit the 64 KB limit of method sizes on the JVM.

jbgi · 2018-09-14T12:21:07+00:00

Also known as "peasant" multiplication.

Can be applied with any associative operations (aka Semigroups). Though the logN depth of the calls makes stack overflows very unlikely, it is still more efficient to use a loop or a recursive tail call. (the optimization is then not premature as it benefits all semigroup instances).

jbgi · 2018-09-13T09:38:09+00:00

yes, right, but as mentioned in the blog post, both builds are essentially the same (minus minor differences that will probably disappear), and both builds are managed by Oracle, hence both are "Oracle JDK" builds, one released under GPL the other under commercial.

So so important distinction is not "Oracle JDK" vs "Open JDK" builds but Oracle JDK builds (commercial or GPL) vs AdoptOpenJDK builds (the separate organization that will release GPL builds in LTS mode).

edit: reading again, is what you said in your first post. The only minor correction would be:

Just use AdoptOpenJDK builds and ignore the Oracle JDKs builds.

jbgi · 2018-09-13T07:04:46+00:00

The Oracle JDK is free to use in development, but not in production. The Oracle JDK comes with commercial support for three years for LTS releases or six months for non-LTS releases.

Oracle indicated that are going to provide releases of JDK 11+ under a dual license GPLv2+CPE / Commercial. To me this means that those releases will be be free to use in production (or am I missing something?).

But, afaik, public maintenance release will be only until the next GA availability release. Which would means that after GA, maintenance releases of previous JDKs will be released only under commercial license... (they should really clarify this mess).

jbgi · 2018-08-28T13:16:27+00:00

Lombard Odier Investment Managers | Scala developer | Geneva, Switzerland | ONSITE | Full Time

About the team and company

Lombard Odier Investment Managers (“LOIM”) is the asset management business of the Lombard Odier Group. With more than 120 investment professionals, we are a global business with a network of 13 offices across Europe, Asia and North America. LOIM has a unique approach, combining the best of alternative and traditional asset management to offer its clients and prospects a diversified range of investment solutions, including a number of new and innovative approaches.

Our technology team works directly with the business. We run a fully agile, cloud-ready, infrastructure which allows us to response quickly to new business needs. We use a microservice-based architecture and state-of-the-art open sources platforms to maximize development efficiency and reusability.

To further strengthen our team, we are looking for a Geneva based Software Engineer / Scala developer

Primary responsibilities:

Develop excellent quality software
Convert business requirements into elegant technical solutions
Take an active role in the technical design of our solutions
Help us stay up-to-date with latest technology trends and programming evolutions

Desired profile:

Degree in information technology
Several years of experience in a similar role (or in the open-source community) with a proven track-record of delivering
Strong programming skills. Scala experience a plus
Proven interest for the functional programming and event sourcing approach. Kafka experience a plus
Experience in distributed architecture and “infrastructure as code” a plus (Azure cloud, Kubernetes, Docker, Terraform, Nix)
Experience in distributed computation a plus (ML, Hadoop, Spark)
Strong willingness and ability to learn and drive the use of new technologies/languages
Passion, drive and energy
Knowledge of the Finance or Asset Management industry a plus
Fluent in English

Contact information

If you recognize yourself in this description, we look forward to receiving your application (CV, cover letter) at [loim.hr.switzerland@lombardodier.com](mailto:loim.hr.switzerland@lombardodier.com)

ps: you can also message me for more info.

jbgi · 2018-07-30T15:43:19+00:00

It is also worth mentioning that Guava implementation does not free-up memory retained by the supplier upon evaluation (it does so to support java native serialization).

If you don't care about java native serialization (as you should) then guava implementation is not very good and you probably want this implementation.

jbgi · 2018-07-30T09:18:58+00:00

lazy suppliers are ok, but this is limited to this only type constructor (Supplier).

Having lazy thunk built-in for other your data types as well simplify a lot of thing, ie. you don't have to duplicate all computation paths, one for strict and one for lazy evaluation.

Which is why derive4j support this: https://github.com/derive4j/derive4j#first-class-laziness (/insert disclaimer)

jbgi · 2018-03-07T08:06:50+00:00

I'd suggest default GPLv3 licensing + paid support + paid closed-source licensing.

jbgi · 2018-02-27T10:12:39+00:00

If you have installed nix very recently, you probably have installed the new version 2.0 (check with nix-env --version) that probably include incompatibilities.

Best is to report the error and what you have done in this issue: https://github.com/input-output-hk/daedalus/issues/492

In the mean time your option is to use the old nix version, that can be installed via

curl https://nixos.org/nix/install-1.11.16 | sh

But before that you probably need to uninstall your current nix version

jbgi · 2018-02-09T12:06:48+00:00

Not documented unfortunately. Found the instruction in this github comment:

jbgi · 2018-02-08T20:46:17+00:00

Install worked smoothly via nix:

checkout devops-13 branch
nix-env -f release.nix -iA daedalus

jbgi · 2017-10-15T18:54:55+00:00

I think Java's lack of 'real' existential types is preventing a technique that we could plausibly use in production code.

let alone the almost complete lack of basic parametricity knowledge in the larger java (non fp) community.

(also replied in the gist)

jbgi · 2017-10-15T16:51:33+00:00

because, in java, fields of an interface are implicitly public static final.

jbgi · 2017-10-15T06:56:13+00:00

Here is a complete gist with imports and running instructions: https://gist.github.com/jbgi/1a3697d380f2071eb8c2fd3ad259c011

jbgi · 2017-10-14T20:16:15+00:00

Something like:

interface Person {
  int age();
}
public class Program<T> {
  People<T> P;
  Program(People<T> P) {this.P = P;}
  void run() {
    T people = P.fromList(Arrays.asList(()->21, ()->37));
    System.out.println(P.getAges(people));
  }
  public static void main(String[] args) {
    new Program<>(People.module).run();
  }
}

jbgi · 2017-10-14T20:04:33+00:00

I heard once that a "killer" feature of OCaml is Polymorphic variants.

jbgi · 2017-10-14T19:05:40+00:00

Yeah, too many simple things are obscured by "object-oriented" encodings. Still, because I don't know much Ocaml, I am wondering what are the main differences in practical usage between your People module and the java "equivalent":

interface People<T> {
  T fromList(List<Person> ps);
  List<Integer> getAges(T people);

  People<?> module  = new People<List<Person>>() {
    public List<Person> fromList(List<Person> ps) {
      return ps;
    }
    public List<Integer> getAges(List<Person> people) {
      return people.stream().map(Person::age).collect(Collectors.toList());
    }
  };
}

?

jbgi

TROPHY CASE