Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The APL Source Code (2012)

computerhistory.org

Post reply on HN
Print view View original

51–60 of 61 posts

Re: The APL Source Code (2012)

#51

Post by camdv »

pncnmnp wrote: post #15
coldcode wrote: post #13

I always loved APL when I was a student around 1980, I had access to the little IBM "transportable" that supported APL and Basic, I think it was the 5100 or 5110. I remember writing a little table tennis game in APL, which was likely unreadable to me a day later.

Sounds silly, but do you have the source code for your table tennis game? If not, do you remember the logic you used? Was it using Graphpak? I am curious as to how one would write a table tennis game without any conditionals.

APL can branch on conditional to a specific line or label, or fall through to the next line.

Re: The APL Source Code (2012)

#52

Post by geocar »

MrBuddyCasino wrote: post #35
geocar wrote: post #27

Earlier quoted context omitted.

If a string (or a file or whatever) is "just" an array (of bytes; characters, again: whatever), then yes.

If that means "you don't get much more than what C offers", then I'll take that as a no. I18N, Unicode, Regex, built-in string manipulation functions, character set conversions and efficient data structures are table stakes at this point.

Sigh.

No, it’s quite a bit more than C offers, which has a paltry twenty-eight “operators”, none of which “work” on arrays. Most of the libraries in C and C-like languages have huge libraries because getting those twenty-eight operators to do anything can be a lot of work if you don’t think about it much.

In contrast, Iverson has more than 50 excellent operators, sensibly extended to arrays. Not all APLish languages have all the operators, but the choice about what they do have typically considers how all of Iversons operators can be/are used and how/when they can be implemented in terms of each other. This is largely a matter of taste.

And better symbols means better ideas. Some things are just more obvious in APL. And once you see it, you can take it with you.

When using C, I don’t typically use the C library, or libraries for any of those things you mentioned, because they just aren’t that complicated once you have seen APLish solutions to those problems. And that’s a good thing because less code means less bugs.

Re: The APL Source Code (2012)

#53

Post by tluyben2 »

rscho wrote: post #46
MrBuddyCasino wrote: post #35

Earlier quoted context omitted.

If that means "you don't get much more than what C offers", then I'll take that as a no. I18N, Unicode, Regex, built-in string manipulation functions, character set conversions and efficient data structures are table stakes at this point.

APL is very decent at string manipulation. I could try to explain why, but I am afraid that you'll have to see for yourself to understand why what you wrote is both true and not very applicable to APL.

This is indeed part of what I meant to see before in this thread; it is very hard to convince people, who are kind of biased already by the syntax and the 'old age' of the language, to just try it out for a while. It's the same issue with Lisp/Scheme; if you do wrestle through Common Lisp: A Gentle Introduction and/or SICP, you'll see things in a different light, probably forever and for the better. But it takes (a lot of) effort and if you are biased against something from the start, that's not going to stimulate you much.

Re: The APL Source Code (2012)

#54

Post by eggy »

alaaalawi wrote: post #10
eggy wrote: post #7

Earlier quoted context omitted.

I actually find it way easier and shorter to review code I've written in J and APL, because it is so succinct and the symbols are well defined. Having to review something that is a paragraph or one page of code is much easier than following pages of other programming languages code. You can comment APL as you can in most PLs, and with the REPL-like dev environment, you can test pieces of code for verification quite i…

we need just the correct expectations. APL is like mathematics for me. i need to read it several time to understand dense unfamiliar terms and formulas. same goes for APL. it is not the typical language which i assume can be read while driving

I'd argue you could view 2 lines of APL while driving with less distraction then flipping the screen or page to read your 2 pages of code in most other PLs.

Re: The APL Source Code (2012)

#55

Post by eggy »

trenchgun wrote: post #40
eggy wrote: post #7

Earlier quoted context omitted.

I actually find it way easier and shorter to review code I've written in J and APL, because it is so succinct and the symbols are well defined. Having to review something that is a paragraph or one page of code is much easier than following pages of other programming languages code. You can comment APL as you can in most PLs, and with the REPL-like dev environment, you can test pieces of code for verification quite i…

What are you using April for?

I have always liked Lisp and array languages, so I am finding my footing with April, since it is very flexible. You can write predominantly in one or the other, but I am finding it easier to do the math and array stuff in APL, and the glue in Lisp. Right now I am experimenting with creating some generative art and music with CM (Common Music, a Lisp music composition system that lends itself well to creating algorithmic music) and using APL to create the patterns for CM as arrays and composed functions. I want to add graphics and animations to the code once I get CM working with April. I just started learning April, and I am having so much fun with it, I need to stay focused on my original task!

Re: The APL Source Code (2012)

#56

Post by eggy »

trenchgun wrote: post #40
eggy wrote: post #7

Earlier quoted context omitted.

I actually find it way easier and shorter to review code I've written in J and APL, because it is so succinct and the symbols are well defined. Having to review something that is a paragraph or one page of code is much easier than following pages of other programming languages code. You can comment APL as you can in most PLs, and with the REPL-like dev environment, you can test pieces of code for verification quite i…

What are you using April for?

Another parallel for Rust is Rust and BQN. BQN is a new array language, and you can run it within Rust sort of like what April does for Lisp and APL.

https://detegr.github.io/cbqn-rs/cbqn/

Re: The APL Source Code (2012)

#57

Post by MrBuddyCasino »

geocar wrote: post #52
MrBuddyCasino wrote: post #35

Earlier quoted context omitted.

If that means "you don't get much more than what C offers", then I'll take that as a no. I18N, Unicode, Regex, built-in string manipulation functions, character set conversions and efficient data structures are table stakes at this point.

Sigh. No, it’s quite a bit more than C offers, which has a paltry twenty-eight “operators”, none of which “work” on arrays. Most of the libraries in C and C-like languages have huge libraries because getting those twenty-eight operators to do anything can be a lot of work if you don’t think about it much. In contrast, Iverson has more than 50 excellent operators, sensibly extended to arrays. Not all APLish languages…

So if I understand you right, APL treats strings as arrays of whatever. This makes sense and isn't particularly hard to understand. Is there a way to treat Unicode strings as arrays of graphemes, instead of bytes or codepoints?

Re: The APL Source Code (2012)

#58

Post by rak1507 »

MrBuddyCasino wrote: post #57
geocar wrote: post #52

Earlier quoted context omitted.

Sigh. No, it’s quite a bit more than C offers, which has a paltry twenty-eight “operators”, none of which “work” on arrays. Most of the libraries in C and C-like languages have huge libraries because getting those twenty-eight operators to do anything can be a lot of work if you don’t think about it much. In contrast, Iverson has more than 50 excellent operators, sensibly extended to arrays. Not all APLish languages…

So if I understand you right, APL treats strings as arrays of whatever . This makes sense and isn't particularly hard to understand. Is there a way to treat Unicode strings as arrays of graphemes, instead of bytes or codepoints?

Dyalog APL does this by default.

Re: The APL Source Code (2012)

#59

Post by mlochbaum »

rak1507 wrote: post #58
MrBuddyCasino wrote: post #57

Earlier quoted context omitted.

So if I understand you right, APL treats strings as arrays of whatever . This makes sense and isn't particularly hard to understand. Is there a way to treat Unicode strings as arrays of graphemes, instead of bytes or codepoints?

Dyalog APL does this by default.

It does code points, not graphemes. Graphemes are a pretty niche thing, I believe? Raku's the only language I've heard of having built-in support rather than using a library.

Re: The APL Source Code (2012)

#60

Post by rak1507 »

mlochbaum wrote: post #59
rak1507 wrote: post #58

Earlier quoted context omitted.

Dyalog APL does this by default.

It does code points, not graphemes. Graphemes are a pretty niche thing, I believe? Raku's the only language I've heard of having built-in support rather than using a library.

Ah oops, I misremembered what they were.
Post reply on HN