back

by teleforce·6y ago·view on hn ↗
Hi Martin, thanks for sharing your insightful comments and the improvements list. I think if anyone can do that, the impact will be probably nothing less than the impact of introduction of spreadsheet to do PC industry, and arguably it is still the killer computer application to beat until today.

Just sharing about the improvements of array based programming language from the academia inspired by APL. Two of the most promosing approaches are the Single Assignment C (SAC) from Hertfordshire University, UK (proprietary) and Furthark from Copenhagen University, Denmark (open source). SAC try to the introduce better syntax (as in Algol C) for functional programming array based language with concurrent multi-core CPU support. Furthark also try to better the syntax for programming array language for GPU parallelism by being the more intuitive intermediate language.

From non academic, I would say the closest to your improvements list will be the D programming language. Unlike Python and NumPy, where there is a clunky impedance mismatched, using D it is feasible to create a seamless array based integration by virtue of its CTFE and metaprogramming capabilities including native support for object oriented, imperative and functional programming paradigm. For initial work check the Mir GLAS library for the native D implementation where it has managed to outperform the venerable BLAS/LAPACK Fortran based linear algebra library where normally Python or other programming languages depend on [1].

Additionally D also support native nested functions that can be handy for processing nested multi-dimensional arrays.

I have got the feeling that for seamless CPU, GPU, FPGA and TPU programming integration, there will be based on the Static Single Assignment (SSA) form that is currently being proposed independently by MLIR (from LLVM team) and LLHD (from ETH Zurich). If you have noticed that the SAC is also utilizing this compilation technique as well.

[1] http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

1 comments
Thanks for the comment. I'll look into the items you suggested and see what I can learn.

My perspective on APL going forward is that it must retain symbolic notation. This is a very important element of the value delivered by this language and one of the aspects that tends to be difficult for non-APL-ers to understand (the value) from what amounts to casual contact with the language. You have to live APL for a while before the "tool for though" realization --and the importance of the symbols-- can be understood.

In the '90's Iverson developed J to get around the difficulties technology of the era had with symbols. This was a huge mistake and something that went exactly opposite the "Notation as a tool for thought" idea he promoted for years when describing APL. I watched him give this lecture in person at one of the APL conferences in the mid 80's.

The problem with any language --APL being no exception-- is that a business case must exist for wide adoption. Engineers tend to get lost in the technical minutiae, which is important when you are doing the job but it isn't a requirement for the job to be done. Or put more precisely: IF there is no quantifiable need for APL and a mechanism for better ROI, it is hard to justify shifting entire teams to this, or any other language, simply because we like the technical aspects of it.

At the end of the day things are simple: It either makes sense or it does not. I would LOVE for APL to become relevant again and for it to find mass adoption. I love the language. And yet I understand business and know the probability of this happening is so close to zero it might as well be zero. Sadly.