Live data from Hacker News

A Source Book in APL (1981)

softwarepreservation.org

11–20 of 20 posts

Re: A Source Book in APL (1981)

#11
post #3

target domain softwarepreservation.org appears to be down with an internal error.

33 minutes later, per HN. It's there -- just slow. Took a couple of minutes for the PDF to come down. P.S. Here, I should have just done this, before: http://wayback.archive.org/web/20150908083715/http://www.sof...

P.P.S. I just clicked through to the full thread and see now that gtani did the same (wayback link) 6 minutes ago. Cheers

Re: A Source Book in APL (1981)

#12
post #10
post #3

target domain softwarepreservation.org appears to be down with an internal error.

Slightly faster, and i mean only slightly: https://web.archive.org/web/*/www.softwarepreservation.org/p... (I will actually read carefully but maybe not today, as a former fulltime APL developer).

Any chance you could write a blog post on your experiences? As a young in, Dyalog APL and kdb+ look like amazing pieces of technology that would be great for my job as an engineer who writes a lot of code for analysis and scripting, but nothing for production. I'm sure there are a lot of pitfalls though, so I'd like to hear about the good and bad.

Re: A Source Book in APL (1981)

#15
post #10

Earlier quoted context omitted.

Slightly faster, and i mean only slightly: https://web.archive.org/web/*/www.softwarepreservation.org/p... (I will actually read carefully but maybe not today, as a former fulltime APL developer).

Any chance you could write a blog post on your experiences? As a young in, Dyalog APL and kdb+ look like amazing pieces of technology that would be great for my job as an engineer who writes a lot of code for analysis and scripting, but nothing for production. I'm sure there are a lot of pitfalls though, so I'd like to hear about the good and bad.

What do you want to know about, specifically?

Re: A Source Book in APL (1981)

#16

Earlier quoted context omitted.

Any chance you could write a blog post on your experiences? As a young in, Dyalog APL and kdb+ look like amazing pieces of technology that would be great for my job as an engineer who writes a lot of code for analysis and scripting, but nothing for production. I'm sure there are a lot of pitfalls though, so I'd like to hear about the good and bad.

What do you want to know about, specifically?

Anything and everything, seriously! How easy is it to model in APL, how much did you enjoy coming up with array oriented solutions not possible in standard algol based languages? What type of field did you work in and did others in your group or company know APL? How easy was it to share/read code from/ collaborate with others? What were the pain-points? Do you now use something else that although less terse, you feel is better? If so, why? What were the coolest projects you worked on and do you think APL has a future?

Re: A Source Book in APL (1981)

#17

Earlier quoted context omitted.

What do you want to know about, specifically?

Anything and everything, seriously! How easy is it to model in APL, how much did you enjoy coming up with array oriented solutions not possible in standard algol based languages? What type of field did you work in and did others in your group or company know APL? How easy was it to share/read code from/ collaborate with others? What were the pain-points? Do you now use something else that although less terse, you fee…

While I’m learning kdb+, Dyalog remains my favourite language for hacking and is likely to remain so for much of the publishing work I do, because of its solid UTF-8 support.

Iverson was on to something with his iterators. I am still getting insights decades later. When I use control structures like for-loops (even in APL) it feels like talking with my thumb in mouth.

Re: A Source Book in APL (1981)

#18
post #17

Earlier quoted context omitted.

Anything and everything, seriously! How easy is it to model in APL, how much did you enjoy coming up with array oriented solutions not possible in standard algol based languages? What type of field did you work in and did others in your group or company know APL? How easy was it to share/read code from/ collaborate with others? What were the pain-points? Do you now use something else that although less terse, you fee…

While I’m learning kdb+, Dyalog remains my favourite language for hacking and is likely to remain so for much of the publishing work I do, because of its solid UTF-8 support. Iverson was on to something with his iterators. I am still getting insights decades later. When I use control structures like for-loops (even in APL) it feels like talking with my thumb in mouth.

Can you go into more details please? How's your experience with kdb+?

Re: A Source Book in APL (1981)

#19
post #10

Earlier quoted context omitted.

Slightly faster, and i mean only slightly: https://web.archive.org/web/*/www.softwarepreservation.org/p... (I will actually read carefully but maybe not today, as a former fulltime APL developer).

Any chance you could write a blog post on your experiences? As a young in, Dyalog APL and kdb+ look like amazing pieces of technology that would be great for my job as an engineer who writes a lot of code for analysis and scripting, but nothing for production. I'm sure there are a lot of pitfalls though, so I'd like to hear about the good and bad.

I ran it on a cluster of 5 of the largest mainframes available at the time, so i don't know what it'll be like stability and footprint-wise on linux/12G memory. I liked the language but i see what people are doing in R, python, julia especially, and numeric libraries in clojure, go, scala, rust, etc they're pretty impressive. One frequent limitation is not too many langaugea have complete wrappers for either of the 2 API's that CUDA exposes, which is pretty important in deep learning.

so if there are tangible advantages to APL today, it's not that obvious.

Re: A Source Book in APL (1981)

#20
post #19

Earlier quoted context omitted.

Any chance you could write a blog post on your experiences? As a young in, Dyalog APL and kdb+ look like amazing pieces of technology that would be great for my job as an engineer who writes a lot of code for analysis and scripting, but nothing for production. I'm sure there are a lot of pitfalls though, so I'd like to hear about the good and bad.

I ran it on a cluster of 5 of the largest mainframes available at the time, so i don't know what it'll be like stability and footprint-wise on linux/12G memory. I liked the language but i see what people are doing in R, python, julia especially, and numeric libraries in clojure, go, scala, rust, etc they're pretty impressive. One frequent limitation is not too many langaugea have complete wrappers for either of the 2…

This lets you access CUDA with APL

https://github.com/arcfide/Co-dfns

Post reply on HN