In Praise of APL: A Language for Lyrical Programming (1977)
1–10 of 60 posts
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#2I can imagine that a fork of GNU APL, re-written in FORTRAN with multi-threaded and maybe distributed computing support, would be an amazing mathematical tool. Something that's super fast and scales really well, and makes mathematical operations really easy.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#3> First appeared in SIAM News, 1977-06.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#4I can imagine that a fork of GNU APL, re-written in FORTRAN with multi-threaded and maybe distributed computing support, would be an amazing mathematical tool. Something that's super fast and scales really well, and makes mathematical operations really easy.
Gnu APL has multi core support for certain computations and you can fork APL child processes and interact with them. So not quite multi threaded but still very useful for heavy duty work where you want to have a great deal of concurrency.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#5> I am firmly convinced that APL and LISP are related to each other along an important axis of language design and that acquiring simultaneous expertise in both languages is possible and desirable for the beginning student. Were they unified, the set of tasks that succumb to terse, flexible and expressive descriptions will enlarge enormously without overly increasing the intellectual burden on the student over his initial 16 week contact period.
In the context of setting the objectives for education in computer science for general students, I like the idea that the objectives are to (a) understand the limits and potential of computation and (b) achieve fluency in programming such that one can conceive of and describe computational processes for a wide range of tasks.
He explicitly suggests that fluency in using other people’s programs not be an objective. Perhaps this is a bit idealistic since most programming in the wild today consists of glueing together other people’s programs. But it seems like the right objective when possible—-in some ways it is a view of computer science as a liberal art.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#6Related article posted on HN recently:
APL is more French than English [https://news.ycombinator.com/item?id=18640451]
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#7I can imagine that a fork of GNU APL, re-written in FORTRAN with multi-threaded and maybe distributed computing support, would be an amazing mathematical tool. Something that's super fast and scales really well, and makes mathematical operations really easy.
I think KDB might be what you’re looking for. It’s very efficient and widely used in finance. It’s pretty expensive, but I believe you can use it for personal use for free (there might be a single core restriction I think).
As an aside, KDB devs make bank, like salaries >500k
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#8I can imagine that a fork of GNU APL, re-written in FORTRAN with multi-threaded and maybe distributed computing support, would be an amazing mathematical tool. Something that's super fast and scales really well, and makes mathematical operations really easy.
Gnu APL has multi core support for certain computations and you can fork APL child processes and interact with them. So not quite multi threaded but still very useful for heavy duty work where you want to have a great deal of concurrency.
Yes! I'm imagining a value proposition where APL is as fast as C or Fortran, on distributed systems, because at that point it would probably evaporate most of Matlab, Mathematica, and probably TensorFlow's users.
Can you imagine? APL is an amazingly powerful language. It's easy to write nearly any mathematical function in it. What if it was faster than every other mathematical language? It would probably dominate the market overnight.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#9Earlier quoted context omitted.
Gnu APL has multi core support for certain computations and you can fork APL child processes and interact with them. So not quite multi threaded but still very useful for heavy duty work where you want to have a great deal of concurrency.
Yes! I'm imagining a value proposition where APL is as fast as C or Fortran, on distributed systems, because at that point it would probably evaporate most of Matlab, Mathematica, and probably TensorFlow's users. Can you imagine? APL is an amazingly powerful language. It's easy to write nearly any mathematical function in it. What if it was faster than every other mathematical language? It would probably dominate the…
As mruts pointed out above, kdb+/q provides what you're imagining - it provides fantastic distributed computing support via its IPC protocol and also has multi-core support.
Re: In Praise of APL: A Language for Lyrical Programming (1977)
#10Earlier quoted context omitted.
Yes! I'm imagining a value proposition where APL is as fast as C or Fortran, on distributed systems, because at that point it would probably evaporate most of Matlab, Mathematica, and probably TensorFlow's users. Can you imagine? APL is an amazingly powerful language. It's easy to write nearly any mathematical function in it. What if it was faster than every other mathematical language? It would probably dominate the…
As mruts pointed out above, kdb+/q provides what you're imagining - it provides fantastic distributed computing support via its IPC protocol and also has multi-core support.
Multi-core is priced for big financial institutions, though. Only thing you or I could afford is the 32 bit single-core.