8 ms·

Getting Started with APL (2017)

97 points by lelf 7y ago

pmoriarty 7y ago
A big hurdle for me is that there's no APL interpreter available in my Linux distribution's (Gentoo's) package manager. So I can't easily install it as I can most other languages, using my distro's package manager. That means I'm going to have to search out how to get an APL interpreter -- something not even mentioned on in the Getting Started article linked to in this HN post, nor on the Getting Started article on dyalog.tv that the former article links to. That alone is just way too much trouble already. Then there's the issue of typing in all the weird APL symbols. I've reconfigured my keyboard to type special symbols a long time ago, but I don't even remember how to do that now so it'd be nice if there was some straightforward documentation on how to do that for APL on a typical Linux system -- or, better yet, some easy plug-and-play way to do that. That would eliminate yet another major hurdle.
- haolez 7y ago
  Using your distro's package manager to setup your development environment is usually cumbersome. Perhaps it would be better to use something like Nix on top of your Gentoo to manage that, or even abusing your ~/.local directory with manual installs of the tools you want.
- smabie 7y ago
  Just try kdb+/q instead. It’s really the only APL derived language that is used in industry. It’s blazing fast and if you get good at it, you can make more money than maybe any other programming language. It’s a very nice environment and the language (q), comes with a great time series database (kdb+). It’s proprietary, but the 32-bit version is free to use, I believe.
  - papercrane 7y ago
    > It’s proprietary, but the 32-bit version is free to use, I believe. They've changed the licensing a few times. Originally the 32-bit version was free for commercial use, then it became non-commercial use only. Now you can get both the 32-bit and 64-bit versions free for non-commercial use, but you're not allowed to run the free 64-bit version "in the cloud". https://kx.com/connect-with-us/licenses/ https://kx.com/connect-with-us/licenses/
  - 7thaccount 7y ago
    I don't have lots of money and my company passed on it as too proprietary, else I'd be all over it.
    - srazzaque 7y ago
      Did you actually see a quote from Kx before making that decision? I've first-hand seen the cost/proprietary argument thrown into the face of KDB, to then see companies proceed down a path of other technologies, with a 10x spend in hardware and dev effort. KDB is insanely tuned.
      - 7thaccount 7y ago
        There are other costs. It is hard enough to find people in my industry with domain knowledge, ability to dig into problems, and SQL skills. Finding enough people to use an array language would be difficult as others in my industry have found. I'd personally be super pumped, but I'm an outlier here. Also, there are costs to getting kicked into something like this instead of something like tsdb or influx.
- jxy 7y ago
  https://github.com/fedeliallalinea/gallifrey/tree/master/dev-util/apl https://github.com/fedeliallalinea/gallifrey/tree/master/dev... I thought Gentoo people despise plug-and-play. This is what I have for xorg Section "InputClass" Identifier "KeyboardDefaults" MatchIsKeyboard "on" Option "XkbLayout" "us,apl" Option "XkbModel" "pc104" Option "XkbVariant" "dvp,dyalog" Option "XkbOptions" "grp:shifts_toggle,caps:hyper" EndSection
  - pmoriarty 7y ago
    "I thought Gentoo people despise plug-and-play." If we did, would we have a package manager? Would Gentoo auto-identify hardware as it booted? Gentoo is mostly plug-and-play, like every other distro. We just have a lot of choice. Thanks for the apl ebuild, by the way. That should make things easier, though it'd be much better if it was part of Gentoo's official portage repo. Thank you also for the keyboard configuration. But how would I switch layouts from US to APL? Also, is there some graphic I can refer to to see which keys will output what APL symbols?
- aidenn0 7y ago
  It's trivial to write an e-build for most software, so if there's not already an APL overlay you can make one in a day.
- 7thaccount 7y ago
  J is the successor to APL and uses standard ASCII and should be in your package manager (or you can install pretty easily with wget and bash) and it is free. I like the APL symbols better though.
  - arcfide 7y ago
    I hesitate to call J the successor to APL. I would currently say that J was/is a step within the evolution of array languages, but many of the concepts of J are being actively integrated into Dyalog APL, and Roger Hui is a part of Dyalog right now. I feel that Dyalog APL is the future of APL, learning from J, rather than J being a strict successor to APL.
    - jodrellblank 7y ago
      But what’s the future of Dyalog? With the passing of John Scholes, then the CTO quitting to “work on his first love, compilers” while Dyalog talks of building compilers, then Gitte Christensen saying in a talk that one reason for changing the download terms is that there aren’t enough young people signing up, then after twenty or thirty years of development one person (Marshall) can go into the codebase and get enormous performance improvements.. I don’t at all mean this to be heckling from the peanut gallery, I have great respect for the people, the tools, the company; but from the distant outside there seems an air of slightly directionless faded grandeur, if you will, like looking at an old-timey cinema. If Dyalog APL is the future of APL, how do you imagine that future?
      - mkromberg 7y ago
        Thanks for your interest in the future of Dyalog! You are absolutely right that 2019 marks a kind of watershed moment for Dyalog. The original two-man development team who built version 1.0 of the interpreter (released in 1983) recently celebrated their 70th birthdays. At the beginning of this year, both of them had reduced working hours to about half time. Geoff Streeter remains in good health, but sadly John Scholes passed away in February. Before Dyalog was acquired in 2005 and Gitte and I came in as CEO and CTO, the team working on Dyalog APL consisted of 5 people. Today that number is heading towards 25, several of whom were hired over the past decade to be ready to take over the work of Scholes and Streeter. Gitte's comment about "not enough" young people signing up needs some context. The problem was actually caused by significantly increased interest in APL, which made us realise that our "classical" registration process was putting potential new users off. It was often taking too long to get people a copy of Dyalog APL because of the manual processing that was required, people were confused by the licensing terms and afraid of using the software – and many young people are just allergic to providing any information about themselves online. Now, APL is available for Windows, Linux (including the Pi) and macOS with no questions asked – for non-commercial use. Losing Jay as CTO was a bit of a blow, but I think we are on the way to recovery. Now that he has completed his PhD on the subject of a parallelizing compiler (research that Dyalog has funded for the last 5 years), Aaron Hsu will join young guns Marshall Lochbaum and Adam Brudzewsky at Dyalog, and we have one more C developer joining the team in the UK in January. We hired two fresh APL consultants in the USA in 2019, and will be looking to hire two more in 2020 to support both existing and new business. I've been in the APL business for 40 years now, and my opinion is that the "kids" at Dyalog are every bit as impressive as Scholes and Streeter were at the same age; the shoes will be filled. There is as much young talent at Dyalog as there has ever been working on any APL interpreter, throughout the 50+ year history of the language. As the team grows, we are able to afford having one or two team members focusing most of their efforts on performance. These efforts have accelerated over time, as first Nic Delcros, then Roger Hui and now Marshall have spent significant time rewriting primitive functions to take advantage of vector instructions and new hashing, sorting and other algorithms that have been evolved over the last four decades. Hardware has evolved in ways which mean that many of the old algorithms are sub-optimal on modern chips where the relative speed of CPU cycles vs memory access is completely different from the Z8000. Yes, Marshall is very good indeed, but I can't see a problem there . Performance has improved consistently in most of the last ten versions of Dyalog APL, and I hope we may see even more spectacular improvements in the next decade, both in the interpreter and in GPU-based parallel compilers. We have much work to do: In addition to language and performance work, we expect Aaron to work with Richard Park, another new recruit who was added to the team last year, to work on training materials and documentation – and with Marshall, Roger and myself on quote evangelism unquote; talks at Lambdaconf, Functionalconf and perhaps some new conferences in 2020 and beyond (invitations welcome!). For decades, Dyalog was a company that made a very comfortable living providing a better APL interpreter to clients who converted to Dyalog APL after initially purchasing an APL system from one of the companies that did serious marketing of APL interpreters: companies like IBM, STSC and I.P.Sharp Associates. Thanks to our recent growth, and the fact that Dyalog APL now has decent tooling not only under Microsoft Windows, but Linux and macOS too, we are now starting to focus on developing new business and attracting the next generation of APL developers. I'm sorry to hear that we appear "directionless" to you. I will admit that it is an interesting challenge to keep existing customers satisfied (which should always remain the first priority for any organisation – put on your oxygen mask before helping others) while also working on attracting completely new groups of users. The rate of development of new language features, development tools and libraries for Dyalog APL is as high as it has been for any APL interpreter in history, at the same time as we are making significant performance improvements. Is there anything in particular that you miss? Aaron's work on using APL as a high-performance tool for manipulating tree structures demonstrates that APL is more relevant than ever before, as a programming language that has a natural mechanical sympathy with modern hardware, and allows relatively unskilled developers to write extremely efficient solutions without using complex tricks. I recently had the pleasure of sharing a podium with Aaron in Mumbai as part of the JioTalks series, where we covered some of the reasons why APL is a tool worth taking a look at in 2020, even though the core of the language is more than 50 years old: https://jiotalks.com/watch/204/home/Morten_Kromberg_&_Aaron_Hsu/Pragmatic_Array_Oriented_Functional_Programming https://jiotalks.com/watch/204/home/Morten_Kromberg_&_Aaron_... Thanks for asking!
- arcfide 7y ago
  Dyalog recently changed its distribution policies and licensing approaches to the APL interpreter, so it's easier than ever to get started on any platform. I would encourage you to leverage this to write a Gentoo portage (or whatever they are using now) build for it yourself and send it out for the world. We have a number of Nix users that come to our APL workshops who have arranged for just such a system on Nix. For typing the APL symbols, I use this: 'setxkbmap -layout us,apl -variant ,dyalog -option grp:lswitch'. I find this to be the most efficient for typing APL. The APL keyboard map comes default on modern Linux distributions. Dyalog APL also has extensive documentation for configuring your APL system on your platform. https://www.dyalog.com/documentation_171.htm https://www.dyalog.com/documentation_171.htm
- arcfide 7y ago
  I've updated the Getting Started page to include a link to the Dyalog APL download page. APL is extremely easy to install now for most platforms. Thanks to Nix users at our Workshops, it is now easy to install on Nix as well. https://github.com/markus1189/dyalog-nixos https://github.com/markus1189/dyalog-nixos This should get you started, though some of the instructions are based on the less friendly download process of v17.0 instead of the streamlined process of v17.1.
7thaccount 7y ago
Unfortunately I don't think Aaron has made any progress on coming up with an APL beginners book yet. I'd certainly be excited to buy a copy though. The only book I've read is the free one on Dyalog's website which is good, but doesn't really help me think in terms of arrays for everything.
- invalidOrTaken 7y ago
  A shot in the dark, but learning Clojure got me thinking in terms of sequences for everything. Not quite the same, but I suspect there'd be non-trivial transfer.
- arcfide 7y ago
  Actually, there is movement in this general direction. My Thesis is now out and available publicly in its final version and should be indexed in the databases shortly entitled "A data parallel compiler hosted on the GPU." This provides a bit of an introduction to some aspects of APL, and includes a background on some of the ideas I've talked about before. Additionally, it is a "handbook" of sorts for doing tree transformations in APL, which is, to my knowledge, the first of its kind. As for the beginner's book, I've come to the general feeling right now that a online video course will be a better fit for APL beginners than a textbook. This is an active project of mine that I anticipate completing some time within the year 2020. You may also want to see my presentations on design patterns for APL and the upcoming videos at FnConf 2019 this year. I am not sure if the APL Training Wheels session was recorded, unfortunately, but the content from that work will be going into the video course.
  - dragonwriter 7y ago
    > As for the beginner's book, I've come to the general feeling right now that a online video course will be a better fit for APL beginners than a textbook. Other than generating emotional responses, I don't find video better than text at anything, and most especially not technical education.
    - arcfide 7y ago
shrubble 7y ago
The Gnu APL interpreter is free, installs easily and the author is not only very responsive on the bug-apl mailing list but very knowledgeable about APL. Recommend you check out this interpreter.
- arcfide 7y ago
  Dyalog APL is also free (as in beer) and easy to install now that distribution has been streamlined. While I am biased, I consider Dyalog APL to be the premier APL interpreter and getting it is a matter of a few clicks on Dyalog's download page: https://www.dyalog.com/download-zone.htm https://www.dyalog.com/download-zone.htm
  - jodrellblank 7y ago
    Nars2000 is also free as in beer and opensource, and is easy enough to install, and is nowhere near as comprehensive as Dyalog but interesting in its own ways (ball arithmetic, combinatorial functions, pi/prime number functions, simpler GUI)
    - arcfide 7y ago
      NARS2000 is always doing some interesting stuff. Morten has said before that if he had to recommend an open-source APL, it would be NARS2000.
qwerty456127 7y ago
AFAIK APL itself is easy and beautiful but bending you mind to interpret complex logic in its model can be tricky.
- arcfide 7y ago
  It's really no more difficult than learning recursion, pointers, memory allocation, type theory, functional programming, iterative programming, OOP, or any other of the myriad techniques that we use for computing. As I mention in my talk on APL design patterns, it's largely a matter of what we have been trained to understand, and there is some evidence to suggest that APL is actually arranged in a manner more natural for the human faculty than most computing languages: https://www.youtube.com/watch?v=v7Mt0GYHU9A&feature=youtu.be https://www.youtube.com/watch?v=v7Mt0GYHU9A&feature=youtu.be
  - qwerty456127 7y ago
    > It's really no more difficult than learning recursion, pointers, memory allocation, type theory, functional programming, iterative programming, OOP, or any other of the myriad techniques You don't really need anything of this to solve a problem with Python and Pandas. I always feel like I wish I'd solve it with APL (because it's beautiful) but end-up just getting the thing done this way :-] Thank you for the lecture, perhaps it is going to inspire me to actually learn to solve real problems with APL.
    - arcfide 7y ago
      Except that you do. Python is a form of OOP/Iterative programming, involves memory allocation, pointers, references, and the like. Pandas requires the skilled application of a general purpose language coupled with a domain-specific vocabulary for your problem space. I maintain that APL isn't fundamentally more difficult. If there is something that you have as an example that you think is just too "hard" to do in APL that is very "easy" in Python and Pandas, please do let me know via email (arcfide@sacrideo.us) as I would love to make sure APL has a good answer to such things (I want to make APL accessible). Since you are talking about statistics and data analysis type things, you may find TamStat of interest: http://www.tamstat.com/ http://www.tamstat.com/ Additionally, don't forget that Dyalog APL also has a full Chart/Graphics system (two, actually), and a large suite of idiomatic expressions for computing many classic analysis problems. There's a number of other integrations that people seem to be unaware of often enough. I very seriously would like to receive from you one example of something you have done that you find too difficult in APL, because if it really is, then we can do better and I'd like to make sure that we do.

97 points by lelf 7y ago

A big hurdle for me is that there's no APL interpreter available in my Linux distribution's (Gentoo's) package manager. So I can't easily install it as I can most other languages, using my distro's package manager. That means I'm going to have to search out how to get an APL interpreter -- something not even mentioned on in the Getting Started article linked to in this HN post, nor on the Getting Started article on dyalog.tv that the former article links to. That alone is just way too much trouble already. Then there's the issue of typing in all the weird APL symbols. I've reconfigured my keyboard to type special symbols a long time ago, but I don't even remember how to do that now so it'd be nice if there was some straightforward documentation on how to do that for APL on a typical Linux system -- or, better yet, some easy plug-and-play way to do that. That would eliminate yet another major hurdle.

haolez 7y ago
Using your distro's package manager to setup your development environment is usually cumbersome. Perhaps it would be better to use something like Nix on top of your Gentoo to manage that, or even abusing your ~/.local directory with manual installs of the tools you want.
smabie 7y ago
Just try kdb+/q instead. It’s really the only APL derived language that is used in industry. It’s blazing fast and if you get good at it, you can make more money than maybe any other programming language. It’s a very nice environment and the language (q), comes with a great time series database (kdb+). It’s proprietary, but the 32-bit version is free to use, I believe.
- papercrane 7y ago
  > It’s proprietary, but the 32-bit version is free to use, I believe. They've changed the licensing a few times. Originally the 32-bit version was free for commercial use, then it became non-commercial use only. Now you can get both the 32-bit and 64-bit versions free for non-commercial use, but you're not allowed to run the free 64-bit version "in the cloud". https://kx.com/connect-with-us/licenses/ https://kx.com/connect-with-us/licenses/
- 7thaccount 7y ago
  I don't have lots of money and my company passed on it as too proprietary, else I'd be all over it.
  - srazzaque 7y ago
    Did you actually see a quote from Kx before making that decision? I've first-hand seen the cost/proprietary argument thrown into the face of KDB, to then see companies proceed down a path of other technologies, with a 10x spend in hardware and dev effort. KDB is insanely tuned.
    - 7thaccount 7y ago
      There are other costs. It is hard enough to find people in my industry with domain knowledge, ability to dig into problems, and SQL skills. Finding enough people to use an array language would be difficult as others in my industry have found. I'd personally be super pumped, but I'm an outlier here. Also, there are costs to getting kicked into something like this instead of something like tsdb or influx.
jxy 7y ago
https://github.com/fedeliallalinea/gallifrey/tree/master/dev-util/apl https://github.com/fedeliallalinea/gallifrey/tree/master/dev... I thought Gentoo people despise plug-and-play. This is what I have for xorg Section "InputClass" Identifier "KeyboardDefaults" MatchIsKeyboard "on" Option "XkbLayout" "us,apl" Option "XkbModel" "pc104" Option "XkbVariant" "dvp,dyalog" Option "XkbOptions" "grp:shifts_toggle,caps:hyper" EndSection
- pmoriarty 7y ago
  "I thought Gentoo people despise plug-and-play." If we did, would we have a package manager? Would Gentoo auto-identify hardware as it booted? Gentoo is mostly plug-and-play, like every other distro. We just have a lot of choice. Thanks for the apl ebuild, by the way. That should make things easier, though it'd be much better if it was part of Gentoo's official portage repo. Thank you also for the keyboard configuration. But how would I switch layouts from US to APL? Also, is there some graphic I can refer to to see which keys will output what APL symbols?
aidenn0 7y ago
It's trivial to write an e-build for most software, so if there's not already an APL overlay you can make one in a day.
7thaccount 7y ago
J is the successor to APL and uses standard ASCII and should be in your package manager (or you can install pretty easily with wget and bash) and it is free. I like the APL symbols better though.
- arcfide 7y ago
  I hesitate to call J the successor to APL. I would currently say that J was/is a step within the evolution of array languages, but many of the concepts of J are being actively integrated into Dyalog APL, and Roger Hui is a part of Dyalog right now. I feel that Dyalog APL is the future of APL, learning from J, rather than J being a strict successor to APL.
  - jodrellblank 7y ago
    But what’s the future of Dyalog? With the passing of John Scholes, then the CTO quitting to “work on his first love, compilers” while Dyalog talks of building compilers, then Gitte Christensen saying in a talk that one reason for changing the download terms is that there aren’t enough young people signing up, then after twenty or thirty years of development one person (Marshall) can go into the codebase and get enormous performance improvements.. I don’t at all mean this to be heckling from the peanut gallery, I have great respect for the people, the tools, the company; but from the distant outside there seems an air of slightly directionless faded grandeur, if you will, like looking at an old-timey cinema. If Dyalog APL is the future of APL, how do you imagine that future?
    - mkromberg 7y ago
      Thanks for your interest in the future of Dyalog! You are absolutely right that 2019 marks a kind of watershed moment for Dyalog. The original two-man development team who built version 1.0 of the interpreter (released in 1983) recently celebrated their 70th birthdays. At the beginning of this year, both of them had reduced working hours to about half time. Geoff Streeter remains in good health, but sadly John Scholes passed away in February. Before Dyalog was acquired in 2005 and Gitte and I came in as CEO and CTO, the team working on Dyalog APL consisted of 5 people. Today that number is heading towards 25, several of whom were hired over the past decade to be ready to take over the work of Scholes and Streeter. Gitte's comment about "not enough" young people signing up needs some context. The problem was actually caused by significantly increased interest in APL, which made us realise that our "classical" registration process was putting potential new users off. It was often taking too long to get people a copy of Dyalog APL because of the manual processing that was required, people were confused by the licensing terms and afraid of using the software – and many young people are just allergic to providing any information about themselves online. Now, APL is available for Windows, Linux (including the Pi) and macOS with no questions asked – for non-commercial use. Losing Jay as CTO was a bit of a blow, but I think we are on the way to recovery. Now that he has completed his PhD on the subject of a parallelizing compiler (research that Dyalog has funded for the last 5 years), Aaron Hsu will join young guns Marshall Lochbaum and Adam Brudzewsky at Dyalog, and we have one more C developer joining the team in the UK in January. We hired two fresh APL consultants in the USA in 2019, and will be looking to hire two more in 2020 to support both existing and new business. I've been in the APL business for 40 years now, and my opinion is that the "kids" at Dyalog are every bit as impressive as Scholes and Streeter were at the same age; the shoes will be filled. There is as much young talent at Dyalog as there has ever been working on any APL interpreter, throughout the 50+ year history of the language. As the team grows, we are able to afford having one or two team members focusing most of their efforts on performance. These efforts have accelerated over time, as first Nic Delcros, then Roger Hui and now Marshall have spent significant time rewriting primitive functions to take advantage of vector instructions and new hashing, sorting and other algorithms that have been evolved over the last four decades. Hardware has evolved in ways which mean that many of the old algorithms are sub-optimal on modern chips where the relative speed of CPU cycles vs memory access is completely different from the Z8000. Yes, Marshall is very good indeed, but I can't see a problem there . Performance has improved consistently in most of the last ten versions of Dyalog APL, and I hope we may see even more spectacular improvements in the next decade, both in the interpreter and in GPU-based parallel compilers. We have much work to do: In addition to language and performance work, we expect Aaron to work with Richard Park, another new recruit who was added to the team last year, to work on training materials and documentation – and with Marshall, Roger and myself on quote evangelism unquote; talks at Lambdaconf, Functionalconf and perhaps some new conferences in 2020 and beyond (invitations welcome!). For decades, Dyalog was a company that made a very comfortable living providing a better APL interpreter to clients who converted to Dyalog APL after initially purchasing an APL system from one of the companies that did serious marketing of APL interpreters: companies like IBM, STSC and I.P.Sharp Associates. Thanks to our recent growth, and the fact that Dyalog APL now has decent tooling not only under Microsoft Windows, but Linux and macOS too, we are now starting to focus on developing new business and attracting the next generation of APL developers. I'm sorry to hear that we appear "directionless" to you. I will admit that it is an interesting challenge to keep existing customers satisfied (which should always remain the first priority for any organisation – put on your oxygen mask before helping others) while also working on attracting completely new groups of users. The rate of development of new language features, development tools and libraries for Dyalog APL is as high as it has been for any APL interpreter in history, at the same time as we are making significant performance improvements. Is there anything in particular that you miss? Aaron's work on using APL as a high-performance tool for manipulating tree structures demonstrates that APL is more relevant than ever before, as a programming language that has a natural mechanical sympathy with modern hardware, and allows relatively unskilled developers to write extremely efficient solutions without using complex tricks. I recently had the pleasure of sharing a podium with Aaron in Mumbai as part of the JioTalks series, where we covered some of the reasons why APL is a tool worth taking a look at in 2020, even though the core of the language is more than 50 years old: https://jiotalks.com/watch/204/home/Morten_Kromberg_&_Aaron_Hsu/Pragmatic_Array_Oriented_Functional_Programming https://jiotalks.com/watch/204/home/Morten_Kromberg_&_Aaron_... Thanks for asking!
arcfide 7y ago
Dyalog recently changed its distribution policies and licensing approaches to the APL interpreter, so it's easier than ever to get started on any platform. I would encourage you to leverage this to write a Gentoo portage (or whatever they are using now) build for it yourself and send it out for the world. We have a number of Nix users that come to our APL workshops who have arranged for just such a system on Nix. For typing the APL symbols, I use this: 'setxkbmap -layout us,apl -variant ,dyalog -option grp:lswitch'. I find this to be the most efficient for typing APL. The APL keyboard map comes default on modern Linux distributions. Dyalog APL also has extensive documentation for configuring your APL system on your platform. https://www.dyalog.com/documentation_171.htm https://www.dyalog.com/documentation_171.htm
arcfide 7y ago
I've updated the Getting Started page to include a link to the Dyalog APL download page. APL is extremely easy to install now for most platforms. Thanks to Nix users at our Workshops, it is now easy to install on Nix as well. https://github.com/markus1189/dyalog-nixos https://github.com/markus1189/dyalog-nixos This should get you started, though some of the instructions are based on the less friendly download process of v17.0 instead of the streamlined process of v17.1.

7thaccount 7y ago

Unfortunately I don't think Aaron has made any progress on coming up with an APL beginners book yet. I'd certainly be excited to buy a copy though. The only book I've read is the free one on Dyalog's website which is good, but doesn't really help me think in terms of arrays for everything.

invalidOrTaken 7y ago
A shot in the dark, but learning Clojure got me thinking in terms of sequences for everything. Not quite the same, but I suspect there'd be non-trivial transfer.
arcfide 7y ago
Actually, there is movement in this general direction. My Thesis is now out and available publicly in its final version and should be indexed in the databases shortly entitled "A data parallel compiler hosted on the GPU." This provides a bit of an introduction to some aspects of APL, and includes a background on some of the ideas I've talked about before. Additionally, it is a "handbook" of sorts for doing tree transformations in APL, which is, to my knowledge, the first of its kind. As for the beginner's book, I've come to the general feeling right now that a online video course will be a better fit for APL beginners than a textbook. This is an active project of mine that I anticipate completing some time within the year 2020. You may also want to see my presentations on design patterns for APL and the upcoming videos at FnConf 2019 this year. I am not sure if the APL Training Wheels session was recorded, unfortunately, but the content from that work will be going into the video course.
- dragonwriter 7y ago
  > As for the beginner's book, I've come to the general feeling right now that a online video course will be a better fit for APL beginners than a textbook. Other than generating emotional responses, I don't find video better than text at anything, and most especially not technical education.
  - arcfide 7y ago

shrubble 7y ago

The Gnu APL interpreter is free, installs easily and the author is not only very responsive on the bug-apl mailing list but very knowledgeable about APL. Recommend you check out this interpreter.

arcfide 7y ago
Dyalog APL is also free (as in beer) and easy to install now that distribution has been streamlined. While I am biased, I consider Dyalog APL to be the premier APL interpreter and getting it is a matter of a few clicks on Dyalog's download page: https://www.dyalog.com/download-zone.htm https://www.dyalog.com/download-zone.htm
- jodrellblank 7y ago
  Nars2000 is also free as in beer and opensource, and is easy enough to install, and is nowhere near as comprehensive as Dyalog but interesting in its own ways (ball arithmetic, combinatorial functions, pi/prime number functions, simpler GUI)
  - arcfide 7y ago
    NARS2000 is always doing some interesting stuff. Morten has said before that if he had to recommend an open-source APL, it would be NARS2000.

qwerty456127 7y ago

AFAIK APL itself is easy and beautiful but bending you mind to interpret complex logic in its model can be tricky.

arcfide 7y ago
It's really no more difficult than learning recursion, pointers, memory allocation, type theory, functional programming, iterative programming, OOP, or any other of the myriad techniques that we use for computing. As I mention in my talk on APL design patterns, it's largely a matter of what we have been trained to understand, and there is some evidence to suggest that APL is actually arranged in a manner more natural for the human faculty than most computing languages: https://www.youtube.com/watch?v=v7Mt0GYHU9A&feature=youtu.be https://www.youtube.com/watch?v=v7Mt0GYHU9A&feature=youtu.be
- qwerty456127 7y ago
  > It's really no more difficult than learning recursion, pointers, memory allocation, type theory, functional programming, iterative programming, OOP, or any other of the myriad techniques You don't really need anything of this to solve a problem with Python and Pandas. I always feel like I wish I'd solve it with APL (because it's beautiful) but end-up just getting the thing done this way :-] Thank you for the lecture, perhaps it is going to inspire me to actually learn to solve real problems with APL.
  - arcfide 7y ago
    Except that you do. Python is a form of OOP/Iterative programming, involves memory allocation, pointers, references, and the like. Pandas requires the skilled application of a general purpose language coupled with a domain-specific vocabulary for your problem space. I maintain that APL isn't fundamentally more difficult. If there is something that you have as an example that you think is just too "hard" to do in APL that is very "easy" in Python and Pandas, please do let me know via email (arcfide@sacrideo.us) as I would love to make sure APL has a good answer to such things (I want to make APL accessible). Since you are talking about statistics and data analysis type things, you may find TamStat of interest: http://www.tamstat.com/ http://www.tamstat.com/ Additionally, don't forget that Dyalog APL also has a full Chart/Graphics system (two, actually), and a large suite of idiomatic expressions for computing many classic analysis problems. There's a number of other integrations that people seem to be unaware of often enough. I very seriously would like to receive from you one example of something you have done that you find too difficult in APL, because if it really is, then we can do better and I'd like to make sure that we do.