Wiki/Report of Meeting 2024-08-08

Report of Meeting 2024-08-08

Present: Ed Gottsman, Raul Miller, Devon McCormick and Bob Therriault

Full transcripts of this meeting are now available below on this wiki page.

1) Bob mentioned that Chris had contacted him with instructions to log in to the wiki. Raul was able to log in and get the log files on their way to Ed to be interpreted.

2) Bob will only be available for two J wiki meetings until November. The next two weeks Bob will be involved with Iverson College, so the next meeting will be August 29th. After that Bob will be going to Italy for 6 weeks.

3) Ed will take the information that Raul has given him and create a bar chart of the most visited pages. Bob says this might be useful when we move on to the new format to evaluate the change in behaviour on user page visits.

A general discussion then began.

4) Ed would like to work on creating conversations in the J community and the most common are the J forums. The forums may be a good place to increase the traffic. Devon pointed out that the forum represents people that are already interested in J and that outreach may be a better approach. The recent NYCJUG had a few people who were already on the APLfarm https://aplwiki.com/wiki/APL_Farm which is a discord channel with a lot of array language enthusiasts. The ArrayCast podcast https://www.arraycast.com/episodes also generates interest in the wider community. Ed thinks that the cross fertilization of the different languages could be an effective way to widen the J community. Raul mentioned that there are also communities on Rosetta Code https://rosettacode.org/wiki/Rosetta_Code and Reddit https://www.reddit.com/r/apljk/. Devon mentioned that he had recently given a talk at a Hacker Conference that was outreach. Devon points out that Array languages are often used in finance and that is not a sharing venue. Ed feels that J is most often used for Math, even though it is promoted as a general purpose programming language.

5) Devon mentioned the post by Hillel Wayne about 'Toolbox languages' https://www.hillelwayne.com/post/toolbox-languages/ and Ed feels that you don't want to get pigeon holed that way if the language is general purpose. Devon thinks that logistics may be an area of growth for the array languages. Bob included a link to a Mark Guzdial article https://computinged.wordpress.com/2024/08/05/all-the-reasons-for-liberal-arts-and-sciences-majors-to-learn-to-program-ais-not-really-that-big-a-deal/ that says that there is a necessity to understand computing even when you are using and LLM for programming.

6) Bob hoped to give a talk at Iverson College about what the most appropriate audience for J might be. Bob felt that the primary grades represent the most opportunity, but it was hard to get into the curriculum. Devon and Ed said that they had been unable to interest their kids. Raul observed that it is difficult to turn J into a Christmas gift.

7) Ed wondered if there is an opportunity in domains that have not yet adopted computing. Finance is an area where the users wanted to incorporate formulas in their work and APL was more accessible to subject matter experts. The upcoming episode of the ArrayCast has Paul Teetor, an R programmer who says that the area of statistics and graphics are the primary domains of R. https://www.arraycast.com/episodes/episode86-paulteetor There was also an article by Ryan Hamilton about how KX had been out-maneuvered by open source alternatives. https://www.timestored.com/b/the-future-of-kdb/

8) Large Language Models (LLMS) may have trouble with array languages because they are terse and the amount of programming that is done is relatively small. Ed thinks that there may be a 'business analyst' role for LLM's to ensure that the result make sense in the real world. Testing is another area that humans may be required to develop appropriate unit tests to ensure that LLM's are working properly. Any language could be used for this purpose. Bob wondered if the array languages are better for probing the models which are big linear algebra problems. Raul thinks that is similar to incorporating ArrayFire into J. Raul says if there is an opportunity in anticipating the next big thing in computing. Perhaps LLM's could be turned on themselves to look at their constructs to make more appropriate naming in their foundational programs. Ed mentioned that star programmers are not helped by LLM's as much as the lesser programmers. J may be a better language for pioneer programmers. J is also a very good prototyping language.

For access to previous meeting reports https://code.jsoftware.com/wiki/Wiki_Development If you would like to participate in the development of the J wiki please contact us on the J forum and we will get you an invitation to the next J wiki meeting held on Thursdays at 23:00 (UTC)

Transcript

So the only thing I really had on my agenda

is I started to look at my schedule,

and I think there's only two more meetings that I'm

going to be at before November.

Because next week, I will be on a plane flying to England.

Are you going to present the wiki work, Bob?

No, I was going to talk about audiences for APL.

So I was going to link it back to the podcast more.

Oh, OK.

That's good.

Yeah, because the podcast seems to have

been very successful judging on people who have been

winning the dialogue contest.

[LAUGHS]

Was that right?

Yeah, yeah.

People who-- that's how they heard about it.

Oh, OK.

I didn't know that.

Well, that's good.

Yeah, the last conference I was at,

a couple of people mentioned that.

Oh, that's excellent.

Well, I didn't get that feedback,

but I know that there's been a lot of-- well,

at different times, there's a lot of feedback about things

that we put on.

The most recent one that we did with Johnny Press,

apparently ruffled feathers in the Q community.

So that was fun.

Oh, good.

And ruffled in a very gentle way.

So everybody was quite intrigued by it.

And apparently, Nick Psarris was telling me

that there's lots of people very interested.

Oh, good.

Yeah, yeah.

But that was going to be what I was going to present.

Anyway, I'm going to be on a plane--

yes, I'm going to be on a plane next week.

And the week after that, I'm going to be in Cambridge.

And then I'm back on the 29th.

And then after that, I'm sort of washing out September,

because I'm going to be editing my brains out.

And then I'm going to be away in Italy

for till the 4th of November.

Oh.

You sure you're retired?

I don't think you're actually retired.

That's my current--

I'm not being--

I'm not being played.

I'm retired.

And in the past year, I've been to Sweden, Denmark, Boston,

Washington, Miami, California, Japan.

I think this goes under the heading of people

unclear on the concept.

No, this is the term it's all about.

All right.

My wife agrees wholeheartedly with you, Devin.

She would have me traveling all over the world

if it was her choice.

Yeah, yeah.

Yeah, I just--

I like where I am.

Do you know where you're going to--

when you're going to be in Venice?

It'll be in-- I think we're four days in Milan,

and I think we'll go to Venice.

So 24th, 28th, probably around 1st of October in Venice.

Oh, OK.

I'll just miss you, because I'll probably be there

the last week of September.

Yeah, we're flying on the 24th of September,

and then we're in Milan, I think, for four days.

Yeah, my wife, it turns out, has a conference in Brussels

that ends about a week before we're due to go to Spain.

So there's no point in going home.

Perfect.

And I figured I would just come out and join her

at the end of the conference.

But she tells me, you've already been to Brussels.

Let's go someplace different.

I'm sure the beer isn't as good in Venice, but I'll make do.

Oh, so you're going to go to Venice and then back to Spain?

Yeah.

Yeah, yeah.

Yeah, anyway, if that changes, I will let you know.

But I don't even know whether I can--

my travel organizer is--

I sleep with her.

And she just tells me where to be, and I'm there.

And things work out well.

So you have a social director as well?

Absolutely.

I do.

Yes.

Yeah, and it works for me, because I don't

want to be doing that stuff.

Again, responsibility and power and no, I don't need that.

Well, this time, I did make sure to book my own hotels,

because when I was in Sweden checking into a hotel,

I realized it wasn't under my name.

And they were very lax about it.

But I know that at least hotels here are not lax about you

having a different credit card.

Sure.

So--

Well, then I just have to keep her with me,

because I think she's booked all the hotels.

That's true.

She booked the stuff for me, and it didn't go on the trip.

So--

Oh.

Oh.

Well, she'd always intended not to go, but--

or she equivocated for a while, but then she booked my stuff.

So--

It happened to me once, and I showed-- she booked for me.

I showed up at the hotel.

I said, yeah, checking in, last name is Gotsman.

Oh, welcome.

And she looked down at the record, looked up to--

looked up at me and said, Commander?

[LAUGHTER]

Yeah, that's Barbara.

That's--

I'm Commander Gotsman, apparently, now,

for that hotel, anyway.

Yeah.

So we have one meeting left, and then there's

a big gap in meetings.

But I guess this is a chance to discuss about where should we

be focusing?

Or maybe it's a time to take a break back and then

go back into it.

I don't know.

Well, I will, between this meeting and the next meeting,

try to produce some kind of bar chart around the log,

try to identify robot accesses and pitch them.

And just chart the human accesses.

So maybe I'll have a picture to show next time.

And maybe there'll be something there that's worth--

a string that's worth pulling on,

or maybe we'll just drop it.

So that'll be my contribution to the next meeting.

OK, well, that sounds good.

That sounds good.

That'll give us something to go from.

At the very least, one of the things I was interested in

is when we actually do swing over

to the new category tree sort of organization,

we could compare what you've got now.

We could do another sample later afterwards

to see if there's a difference.

So what end?

Well, just I'm thinking it should

show that people are using different ways of getting

to different parts of the wiki, because the navigation will

be completely different if they're using the navigation.

Well, that we can certainly determine.

Yeah, yeah, well, I'd be interested in that.

If nobody's using it, then it's brand design.

Yeah, yeah.

[LAUGHTER]

Won't be the first time I've developed something that floats

out there and drifts off into--

Oh, oh, oh, oh.

That is the story of my career.

Absolutely, absolutely.

Although, Gary and Peter--

sorry, go ahead.

I was saying, even if you have it, you make a nice tool,

even if no one else uses it, sometimes if you can use it,

and just to put things out in front of people,

they might think it's expertise and all you're using is a tool.

Still works.

Yeah, yeah.

Yeah, there is that.

There is that.

And certain tree falls in the forest and no one hears it.

Does it make a noise feeling to that?

Although, Jack Handy, the Saturday Night Live resident

philosopher, I remember, asked the provocative question,

if trees scream, would we still cut them down?

And answered, maybe, if they screamed all the time

for no reason.

[LAUGHTER]

Yeah, I always think it might be maybe just because there's

a certain element that would cut things down and scream.

And would we have toilet paper if we

weren't cutting down trees?

Yeah, and then would we scream?

Yeah, no, it's good.

It's good.

Yeah, in terms of things to work on next, Bob, I don't know.

I like the idea of pushing on ways to start conversations.

And a lot of the J community conversation

takes place in the context of the mailing list, which

is fairly low traffic.

I think if the traffic increased by a factor of four or five,

I don't imagine anybody would object to that.

Well, maybe two or three.

I don't imagine anyone would object.

So I think it might be worth thinking about things

we could push into the mailing list that

would speed conversation or investigation.

That's all.

Right, yeah, but the mailing list

is sort of talking to people who are already aware of it.

Well, that is definitely true.

And I'm not talking--

I mean, it would be great to expand the universe of J-aware

people.

And I think that the podcast does a lot to help do that.

But just increasing conversation among J developers, I think,

might also be an interesting goal.

Yeah, well, there was a while ago, I think maybe a year ago,

I was wondering if the mailing list was working because

the traffic had fallen off so much.

Right.

And then there's also--

both Cliff Rider and Henry Rich have

taken other approaches, teaching college classes,

and community college classes specifically.

And that occasionally gets people

that stick around or have some further interest in J

after the class.

Yeah, that's how Marshall Lachbaum got started.

Yeah, yeah, Henry's class.

One of the other things I've noticed, and I think, Raoul,

and yesterday at your JUG meeting,

or on Tuesday on your JUG meeting, Devin,

Doug Manella was on.

And I first became aware of Doug Manella through the APL farm

because there's a J channel on that.

And Raoul's a part of that as well,

as well as several other channels for Raoul

because he's able to converse between all

the different ones.

But--

But he seemed reluctant to speak up.

And he was sending texts as well.

And I brought those up.

He seemed happy to elaborate.

Yeah, he strikes me as somebody who's

very big on protocol when it comes to communication.

That's been something that he's been pressing on for the APL

farm and the Discord is to make sure people

are in the right areas talking about the right things.

And it's always nice to have somebody around there policing.

He seems to be able to balance it fairly well.

But he is somebody--

there's sort of, beyond the forum--

I'm definitely watching the forum for sure.

But there is a whole orbit around the array languages

that is outside that.

And occasionally, the people who are on the APL farm

will go back to the forum.

But that's not their chosen way to communicate most

of the time, I think.

Yeah, I should probably--

No, go ahead.

I'm too much in J. I probably should have spent a little more

time in the APL world as well.

That's interesting.

So if there's a penumbra that we could make the J development

community, whose activities we could make the J development

community more aware of, that might be interesting.

I say that not knowing what's in the penumbra.

Well, there's actually a J channel

within the Discord, which is the APL farm.

Does it get any communication?

Is there stuff happening?

Oh, yeah.

Yeah.

No, and there's--

I think the most recent, I want to say,

sort of the event or the topic that just sort of drifted

through was there's a woman developing TinyAPL, which

I guess is a form of APL that she's putting it onto a--

I think she's putting it into Wasm and is just developing

this.

And she actually popped over to the J area

because she was wondering about the modifier trains.

And she was thinking of incorporating those

and seeing how they were done in J.

So those kind of things happen between different languages.

You know, that could be-- that kind of thing

might be very interesting, might start conversations

within the J, within and across communities.

But I'll bet most of the J community

is unaware that anything like that is happening,

that that discussion is taking place,

that that development effort is underway.

Yep.

No, I'm sure they're not aware of it.

I mean, I know Raoul knows about it

because he floats through there every once in a while

and he's seen the posts.

Aside from that-- and Doug would know about it

because he's been through too.

But they're about the only people

I recognize off the forum.

You don't see Henry there.

Or I'm trying to think of who else I might see out of that.

Elijah Storm's there.

Oh, yeah, Elijah's there, although I

haven't seen him recently.

I don't know.

Yeah, it's been a couple--

probably more-- at least a month since I've

seen him post anything.

But you're right, he's definitely in part of that.

And it's quite outspoken.

[LAUGHTER]

But that's not surprising.

No, he just commented on--

he seconded Henry's idea of calling--

Agent.

--Agenda Agent.

Yeah.

That was on the forums.

That was on the forums, yeah.

Yeah.

I think that's a good name, by the way.

I was going to--

I was trying to come up with things like Chair and stuff

like that based on meetings.

But I think--

I kind of liked Agendinator.

Yeah.

[LAUGHTER]

You've got to say it that way.

The Agendinator.

[LAUGHTER]

Yeah.

I'll be back.

Say, Raoul, could you send me references

to other conversations, communities, channels,

mailing lists, forums?

I'm just curious.

I think I'd like to expand my horizons a little bit.

And it sounds, from what Bob says,

that you're plugged into a good deal more than I am.

Well, I mean, I could point you at the Discord

that has the J channel.

And I can point you at Rosetta Code.

Right, that I know about.

I don't think that I've been actively in anything else

that's J-related.

I look at the group on Reddit.

But a lot of it is about the podcasts

and a couple other things.

But it doesn't get a lot of activity.

Yeah.

The stuff I've been involved in historically,

it's kind of more loosely intangential.

But nothing that I think has a real J focus

at this point in time.

I guess what I'm wondering is, is there

any value to trying to bring some visibility to non-J

but array language-oriented activity for the J community?

That's my question.

That's what I'm dancing around, I guess.

And since you're plugged in, you probably

have a better perspective on it than I do.

Yeah, I don't know that I'm plugged in currently.

At various points in time, I've put effort

in various directions.

But currently, I'm not all that focused on such things.

I won't point out I was coming in from a functional language

direction.

But that group has a heavy focus away from array languages.

So it can be diluted down the wash.

Yeah.

I mean, there's possibilities there.

But it would take a significant investment of effort

to make J a visible competitor.

Right.

Well, one of my ideas about speaking at the Hacker

Conference was to try and reach out to a new audience.

But it has to be the sort of audience that

might be interested in it.

The thing that has generally promoted interest

in computer technology in the past

is the quote, unquote, "killer app," which doesn't really

need to be an app or even need to be killer.

But it does need to be something that

solves problems for a group of people

that attracts their interest, something that

breaks new ground for them, and thus

attracts enough interest to make them want to engage.

Yeah.

Well, it's unfortunate because a lot of the work of the array

languages gets done in finance.

And no one wants to share for obvious reasons.

That's an interesting point.

But it still provides a level of stability

for that ecological niche.

A lot of the sales effort--

I'm not sure what else to call it--

over the years, I have the impression,

has been around mathematical programming.

So if you're doing very heavy math of some sort,

J is a wonderful fit.

And that's great.

I love that.

That's not how I use it.

I use it as a general purpose programming language.

And it says right there in the splash page,

J is a general purpose programming language.

But I don't have visibility into very many people

using it that way.

They're using it as a mathematical programming

language.

So that was one reason, Devin, why

I was so happy that you visited the Hacker Conference

and tried to spread the word a little bit.

That was not a mathematical programming application.

It was a more general purpose programming application.

And J really is a wonderful general purpose programming

language.

And it's just not sold, not marketed that way,

as far as I can tell, which is, I think,

I've always thought a terrible shame.

Yeah, in fact, we had a little module

at the NYC Jog on Tuesday about this Hillel Wayne.

He was talking about toolbox languages.

He mentioned J as one of them.

But one of his examples was finding factors of a number.

Yeah, right.

Kind of mathematical-oriented examples.

But actually, a lot of his stuff was kind of like that.

So that's probably him as much as anything.

Well, also, you don't want to be niched like that.

You don't want to be categorized as a toolbox language.

You want to be a general purpose language.

You want to be capable of tackling

any problem of whatever size.

You don't want to be relegated to being reg x, for example.

I think that hits there, is J is a great general purpose

language for an individual.

It struggles being a general purpose

language for organizations, because we

don't have the tutorial for how to tackle

the problems of creating interfaces that

let people work together in that kind of environment.

You get to the point that you see it's simple.

Then how do you teach somebody else the simple stuff?

Because it's not simple for somebody that

doesn't know how to do it already.

And there's definitely things that you

need to do when you're working with a group of people

that are very different from when you're solving

a problem for yourself.

That's an interesting point.

I heard Alan Kay once many, many, many years ago now

explain that most people react to APL

as if they've just found something moist and furry

at the bottom of a garbage can.

And that has always been the reaction

I've gotten with J at various times

when I've tried to pitch it to my various employers

over the years for that problem domain.

It's very hard to get past that.

Very, very hard to get past that.

An employer's going to want--

for an employer to find a language interesting,

they need to know that there's a surplus of people available

that can come and work on it.

And that it's easy to learn, which

is also not going to happen.

Yeah, they don't care that one J programmer could outperform

five C programmers if they have a pool of 100 C programmers

to choose from.

Unless they have some other in on it already.

And they've got some reason to buy in on it already.

Well, it's worse than that.

I mean, they've got legacy code, so they can't give up

their C programmers.

But the other problem is, oh, you

want me to reduce my headcount?

Yes, I'm a manager.

Ambitious.

I want to enhance my career.

Of course I want to reduce my headcount.

That's crazy.

That's not a selling point.

And there's also the issue with having a one-person department

if something happens to that person.

You lose 100% of your programming staff.

It's not a good management decision in that case.

No, it's terrible.

Yeah, I just saw something on Slashdot.

It was someone writing in.

They work for some kind of logistics company.

And they're asking-- not Slashdot, Hacker News--

and asking Hacker News, should we

insource our development, software development?

Because they rely on an external company, which

is very unresponsive and doesn't do a very good job.

But they don't have any other choice.

And I was thinking, gee, in logistics in particular,

ManUgistics had that name for a while

because they were ascendant in the logistics area for a while.

I put a link in the chat of an article

that Mark Gustell, who's an educational researcher who's

specialized in computing languages and teaching

computing to people.

And in this one, I just kind of glanced over it.

But essentially, he's making the case

that a lot of STEM researchers don't need to be programmers.

And they do need to be programmers.

But they don't need to be computer scientists.

And what he's saying is that as the LLMs come in,

that may be more and more common,

that you need to know how to program.

But you're not going to program.

But you need to know the process and how

it's going to work in order to use it effectively.

And so he's suggesting that computing languages should

be part of STEM, even though people in STEM

may never, ever program anything.

And I was wondering whether the array languages fit that.

Because typically, it's easier to pick them up

for people who haven't been trained in computing science

before.

Yeah.

It's interesting.

Well, part of that, too, there's a known second language

problem.

As the second language is sometimes

harder than the first one because you

have to unlearn what you learned with the first one.

Well, and a paradigm change is even--

it's probably harder to learn.

From what I've heard, Arabic is a hard language

to learn if you're English speaking.

But if you're in a close associated language,

it may not be as hard.

Right.

Dutch is apparently the easiest language for English speakers

to learn, strangely enough.

I've heard there's a lot of shared words and things.

Well, a lot of the incognites are probably both

descended from Old Norse.

Yeah, well, according to my brother,

who likes to research stuff like this,

the three hardest languages are Japanese, Chinese, and Arabic,

according to the Naval Postgraduate

School at Monterey.

And it's weird because Arabic at least is alphabetic.

But I guess it's hard enough.

Anyway, so that actually swings back to the talk

I may be giving at Iverson College,

or the colloquium's host at Iverson College,

is what is appropriate audience?

And it's not so much of how do we bring an audience into J,

but how do we--

and I'm looking at more general array languages--

how do we project ourselves out to an appropriate audience?

And the most appropriate audience I've always felt

is ages 6 to 10.

But it's almost impossible to get into curriculum.

Yeah, well, I couldn't get my own daughter to do it.

I couldn't get myself.

And she is a programmer.

Was she a programmer before you tried to get her into it?

No, no, she'd taken one Java class in college.

And after she graduated with the music major,

a friend of hers told her about this hacker school thing.

And because she had a little bit of a portfolio because

of the Java work, she was able to get into it.

And then that launched her paying career.

But you see, that's the sort of thing--

that bridge to something that interests you,

that cool factor, a hacker school, that kind of thing,

will draw people in with other talents.

Yeah.

Well, I did try, because someone--

maybe Rick Sherlock put together a ContraDance app

with stick figures to animate it.

And my daughter calls ContraDance.

And that didn't work.

And anything like this needs a lot of opportunities,

a lot of patience, and a certain amount of--

the remaining factor is--

oops, lead-ins.

Well, yeah, there's always an element of luck.

But I also spent all my time raising my kids to tell them,

you know, luck is what you make.

It's not something that happens to you.

Yeah, exactly.

Yeah, I mean, it is happenstance.

But you can put yourself in positions that are better.

But thanks to Unchance Favors, the prepared mind.

It's very difficult to turn Jay into a Christmas gift,

or any programming language, really, for that matter.

Yeah, well, again, I think a lot of it--

something that's come back into my mind a number of times

is--

I don't know whether any of you used

to watch the old NFL films.

That was in the 1970s.

They'd play this dramatic music.

And then suddenly, all the cameras would go to slow motion.

And it was a half-hour show of what

had happened in the NFL the previous week.

But they had the most amazing cinematographers

shooting reels of 16-millimeter film in these end zones.

So you'd see the ball, the follow focus on the ball,

the laces on the ball as it comes in towards the hands

come up, and it's caught at the crescendo of the music.

And it's all just super dramatic.

And they had this great voice of God announcer over top of it

and build it up.

And it was a half-hour long.

And that, I think, had more to do

with the NFL becoming popular than anything else.

Because before that, the NFL wasn't as big as baseball.

Baseball was a much bigger sport in the States, way bigger.

But then with this-- and NFL isn't as--

if you watch an NFL game-- well, I don't know.

I haven't watched an NFL game.

I watched a CFL game live.

It's not nearly as interesting as watching it on television.

Because you can see replays on television.

You can see analysis of everything on television.

But it's that presentation that I think builds fans.

And starting with slow motion, powerful music, great stories,

and appealing to 14-year-old boys.

And before you know it, you've built a fan for life.

Yeah, and now, I think, especially

with the rise of fantasy footballs,

like there's a channel that just shows all the games that

are playing right now and just the interesting parts of those.

Well, and the difference you see there

is now football has brought betting into itself

in a big way.

They're partnering-- hockey has as well.

Baseball, because of the Black Sox, it's 1919,

really wants to kind of stay away from gambling.

But the other sports are growing because of it.

They're growing an audience in a different direction.

Yeah, I was thinking of shorty and draft kings just today.

Because their numbers look ridiculous.

But it's one of those irrational things that I stay away from.

[LAUGHS]

Maybe the secret is to see the domain that isn't--

and maybe this is why it's now so hard--

is to see the domain that doesn't have a programming

culture yet.

So it was pretty easy for us to get into.

It was pretty easy for--

I don't know the whole story of how APL got into finance.

But there wasn't a lot of programming in finance

in the early days, right?

Yeah.

Yeah.

It was a lot of people who wanted to do stuff.

But it was too--

my theory is too complicated to explain to a programmer who

didn't understand finance.

Like the first options books, Cox and Rubinstein,

they wrote APL code to do the equations.

Because it was too complicated to explain to a programmer

and expect them to get it right.

And it was easy for them to pick up this tool.

And they didn't have Excel.

Excel is one of the things that really hurt APL.

It's because it took away that.

Yeah.

I remember the guy who introduced me to APL

was the guy at Morgan Stanley.

And he was just bitter about the spreadsheet.

And kind of killed it.

It just killed it.

I think in those areas, I think Goodstyle's paper

kind of-- or blog post kind of skirts around this.

Right now, I think if you looked at, say, graduate students

in STEM who aren't computer majors,

you think there's an opportunity there.

But that's what Python has moved into, right?

They've jumped in.

And they've grabbed the science.

It's not maybe the most efficient.

But it doesn't need to be.

Yeah, and Python's probably eaten a lot of R's market share

as well, because R used to be big in anything

related to statistics.

Yeah.

Well, I think we're going to talk

to Paul Teter, who wrote our cookbook on Monday.

Oh, cool.

Yeah, I was talking to him in sort of the tech talk

for setting up to make sure his mic was--

he's going to be really fun.

He's a really good talker.

I talked to him a couple of times.

Really good talker.

Fun.

I talked to him for an hour.

But anyway, I'm sure he'll have some insight and we'll

bounce on that, is where is R going and how does it fit?

But I think it has that niche within statisticians,

because it has so many libraries that are custom made.

That it's probably anchored in there

and is probably quick enough that it may not

be overtaken by Python.

The article by Hamilton--

Ryan Hamilton about KDB+ was on Hacker News.

And I think you referred to it in the end.

Yeah, I did the summary of it.

Yeah.

That sort of indicates that maybe KX

has missed the boat with KDB+, because other groups have

done the end around and there are lower cost

ways of achieving it.

Yeah.

And like I say, based on the K conference

I went to two years ago, they've gone heavily

into making it very Python friendly, which is probably

a smart thing to do.

For a while.

Until the next wave of fads hits.

Yeah.

Which is by LLM.

Well, that's the interesting thing,

which you're using an LLM, it doesn't really

matter what programming language it generates.

You're not going to be looking at it anyway.

You're worried about the tests.

Well--

You're worried about the tests, but you're also

worried about the rough edges and the predefined areas

of effort that you have access to.

Because on the one side you have the--

this is easy, just go off and do this one thing.

And that gets you a few things.

And on the other hand, you have the hardcore hackers

that have a deep understanding that step by step

are breaking new ground.

But then you have all of the domain areas

that you want to tackle that are stretched between the two

and broken by partial understandings

and imperfectly related concepts and novice ideas

and stuff like that.

That's where everybody wants--

that's where the meat is, I guess.

Yeah, the other thing about LLMs,

though, is you're concerned about the size of the training

set.

So it'll probably be better with C++ than with APL.

And in fact, I had proposed when Morten was in town

for the Eclipse that maybe I could write something

on chat GPT for APL.

And he was very skeptical based on the training set issue.

Well, when you're dealing with a programming language,

the training set really should include

a way of bringing the thing that you're training up

with an interactive session or some way of testing things

against a live--

ideally more than one live set.

So it's going to try stuff, see if it actually works.

Because it's one-- you can go out and you can go find stuff.

And there can be a huge body of that, and that's great.

And that does serve a purpose of linking goals up with examples.

But that only goes so far because some of that's

going to be buggy.

And--

Yeah, you're training with crap, and you'll get crap.

Yeah, and at some point, you need

against the actual machine that deals with stuff.

And there, I just--

Well, we're seeing these people on Fire Island next week.

And the guy, he lost his job.

But until recently, he was working as an LLM trainer.

They basically would present him with stuff,

and he would provide the human take on it.

And it was specifically for training language models.

And it was terrible work, too, as you might expect.

That feels like the business analyst role in an agile shop.

And this is something that Raul alluded to a minute ago,

the notion that you've got to convey clearly what it is

that you want.

And BAs convey it to programmers who

understand things like trees and sorting and so on

that BAs don't really understand.

But maybe a BA can just reorient himself to an LLM,

produce code.

And then there's a testing group that's

dedicated to writing tests.

And you still need those guys.

Their job's interesting.

They're more secure than anybody's.

So they're writing tests.

But it's not at all clear what the old programmers

are going to be doing.

You may need one very expert guy, person,

to make architectural decisions, broader decisions.

But I'm not convinced you need a programming shop the way

we usually understand the term.

Yeah.

You're talking about writing tests,

or you're talking about basically testing

the output of the program, testing the way

the program--

Like QA, because you've got to be--

the LLM does something, and you don't know if it's right or not

for someone else.

It's QA, and it's also unit tests.

I'm convinced you'll still need those.

But definitely QA.

Yeah.

Oh, I think so.

Is there a niche there?

I don't know whether an array language would have any

advantage in that kind of a thing.

Not really.

It's a language.

It could be any language.

You can have the LLM output Python, or J, or C,

or whatever, and you don't really care,

because you're never going to look at it.

If you don't like it, you will go back and have the--

you will adjust the prompt to the LLM

and have it generate a new system, a new C system,

or Python, or J, or whatever system.

But you will never look at that source code

any more than you would look at the output of a C compiler's

object code.

But I do-- that's a bit of an exaggeration.

I mean, people do look at the output of C compiler code

in various contexts.

And generally speaking, a lot of consulting context

and a lot of--

you're building a new-- you're building a thing,

and you just build another version of it

rather than getting the whole work.

But the thing that happens when you do that

is you lose track of various use cases that have gone live,

that aren't being tracked.

They're not part of any testing.

It's just kind of how this works.

And so people have learned to use a thing,

and they're using some weird combination that is now

considered a bug by the people that are trying to replace it.

And so it gets some weird fragmentation stuff.

But it's a problem anyway.

That's a problem with the current approach.

Right.

And the way that you work around that

is, one, by the whole alpha test, the beta test release

process, where you make small changes,

and you put out your field and get feedback.

You also have people that do, I guess

you call it, archaeological work, where they go in

and actually do try and understand the old code

and fix it up.

And you have the release model where

you release a new version, and some people

stay on the old version, stuff like that.

So anyways, there's a lot of churn there.

There is.

But I'm convinced that everything we do currently

could be translated to that new model,

and you wouldn't need the programmers anymore,

except in some rare instances, about as rare

as when you have to look at the output of a C compiler

and understand its object code.

And the challenge of coming up with tests

is very similar to the challenge of the legacy enterprise

support thing.

And it's never been fun in the general sense.

There's hobbyist legacy enterprise supports,

except maybe in third world countries where they have--

that's their bread and butter or something, maybe.

I don't know.

But the thing that is pointing out

is turning that kind of tracking of issues

into productizing it, I guess.

How do you help an organization understand itself

when the organization is devoted to throwing out as much as it

can because it costs too much?

Because array languages are essentially

on the foundations of linear algebra,

and the models are basically huge, complicated linear

algebra stacks, is it possible that there

are ways to use array languages to query the model

and get information out that otherwise is almost

impossible for us to assess?

What model?

I'm sure.

Like an LLM model.

Yeah.

Oh, I see.

Oh, no.

It'd be a good way of modeling a model.

Yeah, and they're notoriously opaque.

So there's probably a need for that.

Imagine a multi-billion cell spreadsheet,

and then I'll give you a query language

to go after the contents of that spreadsheet.

Best of luck.

Best of luck.

Yeah, but that's if you're a human being.

But if you're an array language, it's like, well,

that's what I deal with.

That's what I do.

And we just have to--

The problem is to infer meaning from all of those fractions

between 0 and 1, those billions and billions of fractions

between 0 and 1.

There is work going on on that, on trying to figure out

what it is that an LLM knows from the bottom up,

rather than by talking to it, just by looking at the weights.

It's very odd.

Very odd.

It's kind of like integrating ArrayFire into J.

It's kind of a similar kind of a problem space.

You can see that the similarity is there,

but it takes somebody that's motivated and dedicated

to do the heavy lifting.

And then once that happens, other people can go along

and say, hey, look what I can do.

Yeah.

Well, that's what I was talking about.

It sort of gets back to the killer app.

But in that case, it's the old thing in the gold rushes.

The guys that made the money weren't the guys digging the gold.

They were the guys selling Levi's.

You develop a tool, a pick or a shovel,

and now you've got a way to consistently make money

for the next 40 years.

And you've got to be first in.

Gold or not.

And the other problem there is that people--

the whole-- the best return on investment

is when investment's practically zero.

And then people-- that causes people

to see that in action, be very skeptical and cynical,

and avoid breaking ground because they don't--

they've been ripped off a few too many times.

And the whole thing kind of goes off the rails.

But that is an area where I think the array languages have

an advantage because you're not looking

at the huge cost of several hundred programmers

to try and build something.

You can do it with a much smaller group.

But you do hit the skepticism from people

who've been sold bad.

Yeah, they've been sold nothing at too high of a cost.

And now they're skeptical about things that are close to that.

So Ed, when you're talking about testing or developing tests

for these things, what sort of tests are you talking about?

Like--

Two kinds.

Unit tests.

Still think you need unit tests.

But you also need what the QA team, which

where I've worked over the years,

has always been an off-shore team with an onshore component.

But yeah, these are people who put together

test scripts that can drive GUIs.

And they got expected results.

And they compare.

And they run them every night or however often they can.

And yeah, I think those guys are still very much needed.

Yeah, well, I worked in QA for about five years.

Part of it is understanding things that the programmers

don't really understand.

So I had one case.

They were trying to develop the equivalent of a QSIP,

a uniform identifier code, for mortgage-backed securities

or something, which there aren't QSIPs for.

And they came out.

So they basically copied what the stock QSIP people did.

And they got it wrong because they were trying

to compute a tech digit.

And the way they did it, sometimes their tech digit

was 10, which is two digits.

And it was such a battle to get them to understand

why this was wrong.

Right.

So QA does that.

QA finds the fallacies, finds the misconceptions

that the programmers and the business analysts

are laboring under.

So you have a test suite of common questions.

And then you'd evaluate how close

they were to accurate answers.

Is that the approach you take?

Well, that sounds more like unit testing.

But QA is typically the outputs of the program,

the interactions of the program.

So it's the visible parts.

Yeah, so a lot of it is just running the code through,

in some cases, extreme cases to see how it behaves,

and checking a lot of edge conditions and things

like that.

Yeah, and what you could imagine doing

is if you laboriously developed a QA test suite,

you could give the LLM access to it

and say build a system that passes this test suite.

And it would iteratively do that.

You'd probably have to give it some more information

in addition.

But that would be a reasonable first step.

And it's--

And you don't care what language it's programming in.

Yeah, no, no, it's functionality at that point.

What tools are best to use?

Yeah.

Although another approach would be to anticipate,

at some point, LLM is going to be past the fad stage

and into the old new stage.

And whatever is coming up next is going to be replacing it.

So another approach would be to get on the ground floor

of that, which lets you spend time without much competition

until it hits.

Right, the problem is anticipating

what the next thing is.

Yeah, and/or possibly--

If I knew that, I wouldn't have to worry about my retirement.

Oh, that's what marketing's for, right?

Cynical, cynical.

Maybe too much.

I've heard arguments that the LLMs are a bit of a bridge,

but they're still looking at neural networks

as maybe something that's more effective.

Well, they are neural networks, in fact.

They have a neural network component, in effect.

Yeah, but more--

I think they're wondering about more,

not the statistical aspect of it to create it,

but one that's a bit more condensed.

Well, and in some sense, the thing

that distinguishes a neural net from an LLM

is literally a training set.

Right, it's a focus of what you're trying to achieve,

which also kind of argues against it

being good at programming, because if it's

trained in language, and language is not

the same thing as programming.

You can train it on programs.

You can train it on source code.

I mean, there are only about a trillion lines of Python

out there for it to learn from.

Right.

Although the thing that you get there is naming.

In programming, the language itself has a few words,

and it's a very sequential thing how they mean.

But most of the-- when you get into actual programs,

most of the words that are involved

are chosen by the programmer to represent concepts that--

tied interfaces that are independent of the language.

All the language provides is a few keywords and some grammar.

But you don't care if the LLM is producing obfuscated code.

You don't care about naming.

That's the wrong side to think about this.

Or a wrong side, maybe.

I am capable of many wrong sides, Rolf.

I have written programs before where I was not

able to come up with good names.

And the canonical example of that

is when I was doing a parser for--

I don't even remember what the parser was for--

for some config files.

And I think all of the names I used were from the Flintstones.

So I had a yaba and a dabba and so on.

Oh my god.

But that-- my insight there, or pseudo insight maybe,

is that if you put a LLM learning about that,

it's going to see these words, and it's

going to put them in some order.

It's going to train against them in some way.

But value on either the application side or the user

side would be gained from that training effort.

But wouldn't you try and, say, anonymize it

by just putting tokens in the place of names?

Well, yeah.

That's the thing that ultimately you're doing in programming,

or at least in the implementation side

of programming, is you can take names, and you can rename them.

And as long as you know the scope,

you can figure out which names are the same thing.

If you don't know the scope, then

you're relying on the programmer having chosen

either different names for different things

or maybe the same names for the same thing

in different contexts.

There's a whole bunch of subtleties there for naming

and for significance that just--

you have to have a good--

for a firm, you have to have good mechanical knowledge

of how the sequencing works, how the data flows,

and all that stuff.

And if you don't do that, it's noise.

It's a lot of noise.

And yet you have LLMs that can write

paragraphs in the style of Dickens or in the style of Joyce

or--

I mean, those are like programmers, right?

Right.

And if the same-- if there's something out there

that somebody has done thousands of times,

thousands of different people have done thousands of times,

and the LLM just has to pick one of those, it's pretty easy.

But--

When you're doing something new, I

question how effective it's going to be.

Yeah, like--

If there is anything new.

I suspect there is.

Just take something like a web app that takes some--

a web app that takes somebody's name,

it's not going to do anything with it.

A web app that takes weight of measurements,

and in one form, they're numeric,

and in another form, they're some internal form.

And then you translate it to some other unit.

All of a sudden, you've got three different ways

of referring to the same thing.

And that starts getting complicated enough

that the LLM has to have some way of associating

those things in a mechanical fashion

before it's able to treat the domain very well.

I will toss in an optimistic note.

My brother-in-law runs a company that has a programming shop,

and they adopted Copilot early on.

And according to him, it doesn't help his star programmers

at all, because they're working on problems nobody's ever

worked on before for him, at least as far as anyone knows.

But it helps the mediocre or less star programmers

perform like star programmers in terms of functionality

achieved.

It's always been hard to measure that,

but that's his qualitative impression

of what's going on.

But maybe there will always be a role for pioneer programmers,

I guess is what I would say.

And maybe that's a good--

maybe J is a good language for pioneer programmers.

Maybe that's a good way to think about it.

It's always been true that--

I think it's always been true that array programmers are just

basically--

I'll say this-- smarter than the average programmer,

or better at programming than the average programmer.

I feel like the only reason I am comfortable with J

is that I've spent a couple of decades trying

to get comfortable with it.

I don't feel like I had any particular affinity for it

at the outset.

And Stanislaw Lem, the Polish science fiction writer,

observed that if you were sufficiently patient,

you could teach an ape a calculate.

And I've always felt that way about my knowledge of J.

I was just very patient.

You can take bigger steps with J,

which makes it great for prototyping.

Yeah, exactly.

And the way you want to run a--

if you're actually doing programming as a business,

what you want to do is first you want to get something

that approximates--

that does most of the work.

Then you take that apart and have teams of it

go back over it again.

And you know, fill and flush it out.

Rewrite it and flush it out.

Do it using some team-oriented programming language

that lets you feed small bits of work to different people

that do different things.

And--

Prototyping might be a good way to think about it.

I call it pioneering, but maybe that's just prototyping.

Maybe you're right.

Pioneering is a good word, yeah.

Well, and the other thing I think

of when you're talking about your base level programmers

being elevated, the floor coming up because of copilot,

that's the same sort of situation

that Guzdiel's talking about with STEM graduates.

You need something to bring you up a level.

You don't need to be a star programmer,

but you should know basics of programming

or working with a computer before you actually

start working with one.

It's like an essential knowledge.

And I think in that sense, the array languages actually

are probably easier to access than a lot

of the procedural language, their loops,

and all the ceremony that has to go into programming.

Yeah.

I mean, it's always attracted to me

is the absence of unnecessary cruft.

Like just for me, having to say, OK, this is going to be an int.

And maybe way on down here, you're

going to exceed the limits of an int,

and then you'll have serious problems.

Well, and how many lines are there

between where you declare something and where you use it?

And then it changes, and then you change again.

And now you're having to look at pages of code

to find out what's going on as opposed to maybe 10

lines of an array language, which

seems to be easier to keep in your head

when you know the idioms that it's built on.

Yeah.

Depends on the kind of program you're doing.

If you're trying to solve a problem,

and you have the concept, and you're

trying to get to machine, then something like J is great.

If you've got some program that it's out there,

you've got a whole bunch of people working on,

you want those itty bitty baby steps,

because everybody's stepping over everybody else,

and you've got to have some way of resolving the conflicts.

And so you don't want people taking big steps

you want people taking tiny steps.

Yeah.

Was that an argument for verbosity?

Sort of.

The way of creating--

Well, it's like--

--people can work it?

Think of it in military terms.

If you have somebody out there doing scouting,

that's one thing.

But if you have a whole battalion out there

of people that are supposed to be working together,

they all need to stay in step and go--

they aren't going to be very good scouts,

but they can do a lot more of the stuff that they do do.

And that comes back to Ed's pioneering program.

I mean, the scout is a perfect analogy for--

It's a similar-- or like if you're

building a suspension bridge, the first thing you do

is get a string across, and then you start doing the cables

across, and then you start doing foundation.

You build it up from there.

It's-- there's-- a string is great for one thing,

and a cable is great for another thing,

and a bunch of concrete is great for something else.

And the guys that fired the string across

are probably off at the next gorge

while the bridge is being built.

And if-- or if you're talking about building in general,

that there's architecture, and then there's

people that go down and lay the bricks,

and the people that go down and lay the bricks

are going to do a lot of the same thing over and over again.

And they don't-- they're expecting somebody else

that's already done the architecture stuff,

so they're not interested in that.

Yeah.

Hmm.

Anyway--

Once again, I have the feeling that we almost

solved all the problems of the world.

Come on, almost.

Oh, we almost recognized them, at least.

Hopeful, yeah, right.

I'm hopeful for next time.

Well, I'm using it as data for my Who's Our Audience,

because I think it's all useful to me that way.

Yeah.

And I'll be in the air next week.

Yeah.

Jolly old England the week after that, and then back again

for a week before November.

I'll be in the air exactly a week from now.

I have an 8 PM flight.

Yeah, I think I fly to Montreal at about 4 in the afternoon.

Get a Heathrow the next morning, bright and early.

Yeah.

I see if my new noise-canceling headphones

are worth the $100 I paid or whatever.

I'm sure they will be.

I sprang for some Bose earbuds a couple of months ago.

And I have a--

my aunt tried them out.

I cleaned them carefully.

She tried them out.

And she was completely blown away.

She immediately got on Amazon and bought them.

And they really are quite spectacularly good.

I actually own a pair of Bose noise-canceling headphones.

And the earbuds are better.

Wow.

No question about it.

Because I got over the ear.

The main problem I've had is getting it to connect

to the proper Bluetooth because there's nothing

on the headphones to tell you.

Oh.

So I think it's probably something with the phone app.

I haven't learned yet.

But I figure, worst comes to worst,

I'll put on the noise-canceling headphones

and put the little earbuds inside.

And--

Well, you know, my son has--

my son has Schumer's earmuffs.

He doesn't shoot.

He just doesn't like loud noises.

And he will wear earbuds with Schumer's earmuffs over them.

And that is a good solution if you're into that.

Yeah.

All right.

I will offer a closing thought, which

is going back to Ro's point about the difficulty of naming

things.

I have a cousin-in-law who's a lecturer at Trinity in Dublin.

And he has a t-shirt he's very proud of that reads,

there are only two hard things in programming--

cache invalidation, naming things, and off by one errors.

[LAUGHTER]

Yeah.

Yeah.

True.

All right.

Well, Bob, Devin, good luck to you both in your travels.

And I will see you all next time.

OK.

Great.

Take care.

Thanks for now.

Have a good one.

OK.

All right.

Bye-bye.

Thanks so much.