I wish the article was more in line with the title - the title comes up a little bit, but the article is mostly about white-Indian interaction, and not about Indian civilizations. Which makes sense, because the book this is excerpted from is subtitled "Native America from 1890 to present'.

I'm glad you're bringing something like this to the JVM/Scala-ecosystem.

There are some things that I've been interested in asking for in a high level scientific computing library. If you're planning on continuing your visualization library can you please come up with some solution for layout specification? Whenever I'm plotting something and I spend 30 minutes getting all of the data in order the last thing I want to do is fight with the plotting library's label positions because they overlap. Or if I say "Let me take this plot, add some more stacked subplots, and show different catagories" I don't want my labels to be perfect but my scatters to be given a 10x10 pixel box to draw into.

On the HP/numerical computing side of things have you looked into implicit GPU operation types? Something that would let you queue up operations that can be run on a parallel computing system. Basically describe complex operations with the high-level object's normal operations. The objects aren't actually calculating anything, they just organize a GPU kernel in the background. As the final stage you can turn the

    gpumat a(3, 5);
    gpumat b(5, 3);
    gpumat gpu_op_queue = (a * b) + (a * b) * 5;

    function(a, b) operation = gpu_op_queue.compile();
    mat output = operation(some_3x5, some_5x3);

In the backend you'd hopefully be able to great your own types like 'cpumat', 'computerclustermat', or 'gpuclustermat'.

If you had some easy way to generically express extremely parallel numerical operations, an abstract way of implementing high-performance back-ends that take those operations and compile them to GPU kernels, and a visualization engine that doesn't feel like it's from the 80s then your library will really take off.

Personally I feel GPU-optimization and fighting with visualization libraries are the two biggest pain points in scientific computing.

David did a great job with ScalaNLP.

It happens to depend on Breeze. I would point out that Breeze does not support n-dimensional arrays (most tensors), although that is necessary to do in deep learning.

We wrote ND4S and ScalNet to solve that:

https://github.com/deeplearning4j/nd4s

https://github.com/deeplearning4j/scalnet

Moving computation out of Spark's MLlib and into lower level code like C++, as we do with JavaCPP and libnd4j, also improves speed.

https://github.com/deeplearning4j/libnd4j

https://github.com/bytedeco/javacpp

Does Scala have a visualization suite like ggplot, seaborn, matplotlib, or something similar?

What benefits does this provide over existing python or matlab code?

> Scientific Computing, Machine Learning, and Natural Language Processing

These seem to be three very different problems. Is there a reason why the group of them is called "ScalaNLP"? If the libraries are generic enough then shouldn't other uses be possible/supported?

Is there a reason this doesn't have a generic name similar to the SciPy stack?

> If you lean more towards the functional programming paradigm side of Scala then you’ll probably love the following about Rust’s type system

Some of the more popular functional languages have advanced type systems, but not all functional languages are statically typed. Lisp, the granddaddy of all FP languages, is dynamically typed. So is Elixir.

Can we stop conflating FP with static typing?

This appears to be the paper in question:

http://psych.nyu.edu/clash/dp_papers/Ding_nn2015.pdf

Also, for more background on the idea of the "Universal Grammar":

https://en.wikipedia.org/wiki/Universal_grammar