Wiki/Report of Meeting 2023-05-18

Report of Meeting 2023-05-18

Present: John Baker, Ed Gottsman, Dave Lambert and Bob Therriault

Full transcripts of this meeting are now available on the its wiki page. https://code.jsoftware.com/wiki/Wiki/Report_of_Meeting_2023-05-18

1. Ed did not have an update on the J wiki as he is still reviewing the session that Bob had with Stephen Therriault. Ed said he was looking forward to having a session with Stephen in the future, as Ed feels that Stephen has reservations that he would like to explore in search of consensus on the J wiki viewer.
2. The second item was the rebranding of J as the J programming language. John felt that there are not that many primary sources of J information, but that using the term J Programming Language might seem easier for Google searches. Ed wondered what the abbreviation might be and felt that the folks at the Jet Propulsion Laboratory might have issues with that. Ed asked what the motivation for the discussion was. It was agreed that there are not that many sources of information about J, although many people wish that there were more. Dave mentioned that using site:jsoftware.com in a Google search was one way to limit the results of hits and the wiki is also a good source of information. Ed said that Stack Overflow has a <j> tag that is used. John mentioned that it might be a good idea to have a wiki page that lists GitHub repos that have J. Bob added that the new J Wiki Browser has a Bookmark button that allows you to add and remove bookmarks of useful pages.
3. There was a further discussion of using "jios' for the iOS applicatons. This was suggested by Ian Clark as Apple had pushed back on renaming the versions by their version numbers. As it is, J701 is separate from J903, but going forward the "jios" would be used for the umbrella name of the J903 versions. There was some discussion of Ian building a subset of J using Swift, as an investigation into the interface. Ed suggested that there would be howls of protest over which primitives had been selected if it were ever released. This lead to a discussion about whether the number of primitives was an impediment to learning the language. Generally it was felt that there are many languages that are much larger and that the number of primitives should not be an issue. John wondered whether the definition of a variable name in J might include unicode. Consensus was that there would not be any problems with using "jios" as the application name.
4. As an extra item, John asked about the new modular arithmetic that had been added. He felt it was useful for using clocks and other cyclical calculations and had really speeded up with addition of the .gmp extended functionality. Dave found it useful for Project Euler questions.
5. Fold was discussed as an operator that is written in J so was a bit slower than what it would be if it were written in C. Fold was useful for a number of reasons, not the least that it allows J to mirror other languages which have different versions of Fold. J seems to have all the options covered.
6. John asked about the new additions to the Sequential Machine. All agreed that it can be difficult to program, but once programmed is quite useful. The new additions may allow it to apply to a wider number of applications. Dave mentioned that he had considered some type of an interface to program the state machines.

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 general forum and we will get you an invitation to the next J wiki meeting held on Thursdays at 23:00 (UTC) Next meeting is May 25th, 2023.

Transcript

Ed, do you have anything that you would like to show us, or what's the progress report on.

You don't have anything you want to show us.

No, I'm not all the way through your session with Stephen yet.

I'll just say parenthetically, Stephen is good.

I would like to have a session with him at some point if that's possible.

He's got reservations that he's reluctant to communicate in full, there's no question about that.

I'd like to understand those better, I'd like to engage with those reservations.

At some point I would enjoy doing that.

We can talk about that separately, I know there may be issues there, but that is something I would benefit from significantly.

Probably the biggest challenge with that is probably just time zones.

He works till about five at night.

Well I know you're breaking those rules.

But yeah I'll certainly approach him.

He said he thought weekly was a bit much but he said he could come in every two weeks and look at something.

I'm not talking about a standing meeting, I'm talking about one session to hash things out.

My problem is I'm not getting bug reports anymore, which either means it's not really in use or it's working like a charm, accepting the bug report you submitted for groups.

Thank you.

I'm desperate to stay distracted and engaged, and any bug reports that come in are a vast relief in that regard.

But it would also be a relief to be able to get Stephen to clearly express the reservations that he's got and to tackle those and to see if he can come to some kind of consensus.

I think that's a really good idea, but when you get towards the end of the session, he actually talks a little bit about.

.

.

I think he refers to it.

.

.

Well, he refers to it as this feels like stretching to him right now.

Because he says it's not an interface that he would design and it's not an interface that he's seen before.

But he feels like it's a really good stretch into areas he sometimes deals with but this is a different approach.

It was a really good session.

I actually didn't realize it was as long as it was when I started it up, so I didn't allow enough time to finish it before this session began.

I actually took it up to 1.

25 to try to hurry up and finish.

By the way, everybody sounds smarter at 1.

25.

Yeah, they do.

I have to figure out a way to do that in real life.

Yeah, wouldn't that be great.

And then every once in a while you want to trust somebody who really is smart, and you put them at 1.

25 and they're actually frightening, I've noticed.

Yeah, I have nothing to show, but I very much appreciate both Stephen's session and the bug report, and I'll probably have something to show next week.

Okay, that sounds good.

I guess that moves us on to item two, which John was talking about, which was the J naming.

And I hate to have you repeat everything again, John, but you said it very eloquently.

What are your feelings about the naming of JEE as JEE programming language.

Well, I think it's kind of too late to change the name, and the argument that, you know, it's hard to search for, I agree that that's the first thing I kind of thought when I first came across it many, many years ago.

But it's a small community.

there's only a few primary sources.

The wiki is by far the most important, but that sort of points you to pretty much probably half or even more of all sort of existing J reference materials.

So, once you find that, I think you're pretty much home free.

And I think what Eric suggested the other day of just using J programming language to disambiguate things is perfectly fine, you know, as long as people start sort of using that tag, and that battle, that'll pick it up.

I mean, it's, you know, it's not it's not like more more commonly used languages, like if you try, try and search for Python or something like that, you'll find deluge or, or, or just any of the major languages.

But J is small, there's only a few primary sources, I don't think it needs to be be renamed thing.

But more likely to just confuse the few people that do use it.

Hello, Dave.

Thanks for joining.

Ed doesn't have a lot to show right now.

So we're moving along and we're talking about using the J programming language name way of identifying J.

Have you got any feelings about that.

>> J.

J.

I'm sorry.

I do have a question.

Would that, as a practical matter, be abbreviated JPL.

>> Well, the problem is, is there's already a jet propulsion laboratory that's probably much more famous.

>> J.

Yes, I know.

Yeah, see, I just think there are issues here.

The other big source is StackOverflow.

I don't know how big it is, but it's a source, is StackOverflow.

and that's disambiguated too.

They actually have a, I believe they have a JTAG.

- They do.

- So it's not a problem.

- As a person who patrols Stack Overflow, the problem is Java programmers wanting to use JTAG.

But we work on that.

- Sure.

Raul, a long time ago, advocated using site colon Jsoftware.

com and I use that.

- Yeah.

- But I guess there's a lot I've missed that's on the network that, you know, not at our site.

- I think as John said, the biggest source other than the Jsoftware site is the Wiki.

And if you have access to the Wiki, that by far and away is the most, Because some of the information on the J, well quite a bit of the J software site has been brought into the wiki now.

Some of it hasn't, but a lot of it has.

So I would think between those two and some blogs I'm sort of picking up here and there of individuals writing, to me that's gotta be in the 95% of anything J is sort of in that range sources.

So is the feeling that somehow we're missing stuff because of this naming problem, that there's material out there somewhere that Google's not finding because "J" is not a good search term.

What's driving this really.

I think that's a really good question.

It showed up in in the forum, is it Richard Donovan I think, was saying he was having difficulty Googling Jay and felt that this was a big issue with finding information.

But I didn't respond too much in that thread but I really think that there's not that much out there.

That's part of—he may want there to be more out there, but there's not that much out there other than the sources we've already talked about.

So talking to Eric, the reason he wants to go with J programming language, and I think it's interesting that John used the term "disambiguate" because that's exactly what Wikipedia does.

They put programming language in parentheses right after J.

And so essentially it's the same thing as J programming language.

And it's, you know, as a search term, I think it makes perfect sense where Eric, where it came up between Eric and myself was I was looking at the primer to revamp it.

And Eric said, "What do you think about the J programming thing and I hadn't tied it back to that discussion so I thought, what are you talking about.

But I think what he's saying is we really should promote that J programming language wherever we can within the wiki so that it becomes an SEO, a search term.

For people who are looking, it'll drag them to the wiki or drag them to the primer or whatever other resources we're putting in.

It may be a way to start-- But how would they know to use it.

Well, we have to educate people.

That's one thing.

Like, you know, and one of the areas I said to Eric, I'll bring this up on the next array cast.

So if people are listening and they're looking to want to, you know, they get into the array languages, they want to, you know, find out more about them.

If you want to find out more about J, look for J programming language, and that should help.

- Dave mentioned using psych colon.

That seems like a pretty good solution.

Yeah, there's a bunch of different ways of doing, of help, you know, they're all sort of it.

But I think it's something that people sort of move on past really quickly, like, you know, find a few good sources, and then you're home free.

And because there are, you know, there's only a few really good primary sources.

There's some things on the wiki that could help us.

Like one thing I've noticed about GitHub in the last year or so they've, They have this new feature where you can organize all your all your favorite repositories that you're following in your sort of the list that you're that you tag and group that.

So I have I have one group for Jay and another thing that I'm working on.

And I thought, well, you know, people sort of accumulate all the sort of list of their favorite little repos.

That might be a good a good wiki, wiki page, okay, here are all the known GitHub repositories relating to J.

And I'm sure there's probably less than 100.

Make me you know, maybe 200 at the very top.

So a couple pages, you've got big code to start from.

And then of course, when you have repos, you You also have people and other people and so on and so forth.

So I don't really think it's a gigantic issue.

Like once you sort of find a few good sources, I mean, and A has the same problem and so does C.

(laughs) Only C you'll be back to a deluge, you know.

I like that idea of GitHub on a Wiki page.

That's a really good idea, especially for sort of the more advanced users, I think, but, uh, maybe for newcomers as well.

Yeah.

Yeah.

It's, it's, uh, yeah.

The repos are, you know, they're, they're kind of handy because, well, they're, they store the code and, uh, in many cases, the, the person or the entity that's hosting it, they, you know, it sort of tells them what they're using it in relation to or what their other interests.

Sometimes I find that almost more interesting J itself, so, you know.

- The thing that Ed's put in the browser that's really neat and I was talking to Steven yesterday about this is the bookmarks which are exactly for the Wiki what you're talking about for GitHub, is you can bookmark the pages in a wiki and keep it in your own bookmark file.

And that, and you can, if you get tired of that page, it's not useful to you anymore, you just go back to that page from the bookmark file and you unbookmark it and it disappears.

So you really have nice control over the pages of the wiki that you find most useful.

- Okay, well, that could be quite handy.

- It's really good.

[LAUGHTER] Have you seen any of the browsers that Ed's been doing, John.

Just-- and the other day, I was looking, and I noticed the new search thing, the little drop buttons.

So I was piddling around with it and thought, well, that looked kind of handy.

But I haven't played with it very much yet.

The other thing that came up, and this was for me sending out minutes for this was Ian Clark responded because, and this isn't strictly to do with the wiki, it's got more to do with Apple and the J application on iOS.

He's named his updates, he was going by the number of the updates so he had a J901 then he did a J903 and when he tried to do the J903, Apple pushed back and said, "No, we're not going to let you do a new app for every stage here.

We want you to consolidate and you give it a name and then update it as it goes.

But this time we'll let you through.

" So he said, "Well, I'll start the conversation amongst the community.

" His proposal is J-I-O-S.

And the thing that he pointed out in an email to me that was interesting is that it actually is separate from J701, which is the one that Eric did originally.

And so it won't get in the way of 701, which he thinks is important because it's nice to have two versions that you can compare with each other.

But what will happen is JIOS will become the one that follows the progression of the new versions.

And his plan is to write it in Swift.

Is to, right now I think he's using C, but his plan is to transition into Swift.

- All Swift.

Because I think I saw his email thread, because about a couple of weeks ago, the J901 thing and one iOS update just stopped working.

So I deleted it.

And a couple days ago, I reinstalled when I saw this message, Ian's message, I thought, Oh, I'll give this thing a try again.

So I reinstalled it, it does work again, it comes in at least on iPhone 13.

So that that's, and he's made some improvements.

And, and I got the impression just reading the email thread that, that he's that all the front end stuff will be swift, but the back end will still be like the J engine in a C version.

Or does he plan to convert all of the engine in the C engine to Swift as well.

'Cause that's a big chore.

That would be a big job.

- I didn't get that from the post.

- Yeah.

- The post I saw most recently, I'm just trying to think of, I don't think that was a personal post to me.

I thought it was on the forums.

But was Ian talking about taking a subset of J.

He'd been looking for sort of a J minimal kind of primitives.

And the reason he was going for that was because he's thinking of developing J Ian Swift, but he doesn't want to take on the whole language.

He wants to take on a subset that way.

Now I think that would be different than what he's doing with J iOS, but we could, you'd have to ask him to find out.

What was the goal of that.

Why would you try to build a subset of Jay.

I think his reasoning, well I think the main reason is because he's more interested in the UI than the language itself.

So a subset allows him to start playing around with the UI of Swift.

He couldn't deliver that, right.

He can't deliver a subset of Jay to the Jay community without eliciting howls of protest about the subset that he chose, right.

I think that's probably true.

But again, I'm not saying he's going to change what we're referring to as JIOS.

He may leave that as the complete thing, but he might develop something that's like JLite, and that might be a subset, which would be interesting because I'm just thinking over the last couple of weeks, I've had a number of people who are K users talk about the size of the language being an impediment to them.

It's not an impediment.

I know, but you know.

Primitives do not get in your way.

You could ignore primitives that you don't want.

The problem is the documentation.

The documentation has a lot of stuff that gets in your way, arguably.

We need a stripped-down set of documentation.

I can definitely see that, but I don't understand why you have to take a chainsaw to the actual language.

Yeah, because then to do anything you're basically rebuilding all that stuff to put it back in.

I mean, you know, this is such a long battle, like, like Mathematica, how they do it, you know, people argue, it's like an encyclopedia, you know, every known mathematical procedure is coded into that thing.

And I'm every single mathematical user probably ignores 95% of what's there.

And just like you say, yeah, and they do it on intention.

And so I can understand that like, if you want to reduce it to a simple thing and make it really fast and fine.

But if you do that, the minute you get outside of that area where you develop, you're back recoding all the stuff you throw out.

Maybe some people like recoding stuff, but it gets kind of tired after a while.

So if he does that, I would suggest do what the Python Python people did like the howls between I guess one of them what going from one of the versions of Python to the newer one where they changed the nature of strings, everything went Unicode in the new Python, they decided that we're putting all the old ASCII stuff behind from now on.

It's all unicodes.

I know this breaks a lot of stuff, get over it.

And they people have settled, they have said a lot of people, but I the right choice.

So if you're if you're going to re-implement a subset of J, I think probably the same thing might not be bad.

The other thing you might consider is loosening the definition of a name.

Like new, a lot of newer programming languages are getting so you can actually assign Chinese Arabic characters in Unicode as variable names.

And there's good reasons why people would want to do that.

So if you have your grammar, and you just say, okay, everything except everything, all Unicode characters in these blocks can now form names, that might be kind of interesting, you know, you could put in your own little APL characters or, you know, make it look the way you want that that would be different and useful and, and he'd get to play with his UI because, you know, I recently wrote a Python program with Delta X, etc.

and it has variable names, you know, Greek letters.

Yeah.

They accept it.

Yeah, it's, it's pretty common.

I mean, that a lot of the newer languages are pretty tolerant.

And I think that the new C++ standard has some extensions for doing the same sort of thing.

So, you know, in another 20, 30 years, people are going to say, "Gee, that Ken Iverson guy was kind of right about, you know, strange characters.

" The ironic thing is if Unicode had become popular about six years later, six years earlier, there may not be a J.

Because that was part of the ASCII thing was a big deal at that time, because you didn't have Unicode as popular that you'd actually swing over and just reinvent some stuff.

- It's still a problem, but like, some like a Visual Studio code, like the Lean programming language, it has a lot of mathematical symbols in it and then a lot of slash escapes.

And it's pretty good support that if you hover over one of the characters, it'll show you the three or four different ways in which you can type this thing.

But it's still kind of a pain to type it.

You know, I expect that eventually we get to the point where we the keyboard will be a little screen itself.

I mean, people already experimented stuff like that.

But if you could get like a key that changes its glyph, then then typing in Unicode probably just take over people will divide their own subsets, their own languages, and whatever.

But it's it's still a pain to type this stuff, you know.

I guess the argument is always with this.

I look for the symbol on the internet and just copy and paste it.

Oh yeah, I do that too.

Word is very good for that too.

You type in the help and it'll pop up and you can just cut and paste.

Everything has its escape keys and you can never remember it from one app to the next, at least I can.

So whatever Ian's doing with, and I think he's staying with the, just going to have JIOS be the version that follows along with J as it changes.

Does anybody have an issue with naming the iOS version of JIOS.

now.

Pretty clear cut.

Unless it's already taken some way, but then they'll have to come up with some other name.

But yeah.

Someone, maybe several someones have implementations of many of the basic, oh J language written in a subset of the language.

So if you implement, in other words if you implement a subset of the language, you can load a library or something that'll bring in the rest and you might lose the symbols for it but with the names you'd have everything.

Yeah I think Dan Braun had done something with that where he had a number of, he took like almost an axiomatic approach to it.

He took some of the primitives and they defined other primitives in terms of those, so that that smaller group, but I don't think you ever get the speed you do if you've actually taken the interpreter and put it into C.

I think that's the issue with that.

But you can make it give it a very small footprint, I guess, that way.

Anyway, that's the direction I was giving is just start throwing J programming language around as you're introducing things because that will start to become more common use over time and publicize that.

And again, I kind of agree with the sentiment that's been expressed already.

I'm not sure where this comes from in terms of searchability because it doesn't actually increase searchability across the wide internet.

If you're not using J programming language, it doesn't help at all.

And if you're in the areas that are already accessible, it doesn't make much difference, but it may not be a bad way to allow people to do a search if they're not already in the community.

Yeah.

People might search for programming language.

[laughter] Anyway, I think that's probably most of that topic.

Is there anything else people want to bring up or discuss.

One thing I was asking about the new modular arithmetic primitives in the J-beta.

Have any of you played with that yet.

It's kind of cool, actually.

and the determinant to modular arithmetic, it's, yeah, I can see why they probably like Cliff Ryder and a bunch of people held off on doing this in the past because until the arbitrary precision arithmetic was upgraded, it was horrendously slow, but now that the GMP stuff is in there, you can actually do this stuff pretty quickly.

And it's kind of neat, actually, I've already found some uses for it, because it's quite interesting how modular arithmetic partially comes up on clocks and timing.

So that little m dot is pretty handy, you know, just just plug it in and boom.

So that that's kind of kind of a useful extension to the language.

Yeah, so.

I don't think I have a use for it except for maybe with Project Euler.

Yeah, hey, Will.

Is it more efficient than like Encode Decode, which I think is what we would have used in the past as you change to your base and then do whatever addition and then change back again.

not for just strict calculations, but for stuff like the determinant.

And yeah, you definitely I think it is, at least with the GMP stuff in there.

Well, it's just also just a lot easier, more, you know, easier to sort of get your head around it.

In code decode is always, you know, oh, yeah, kind of, oh, yeah, we can sort of do this.

But it's just, it's just kind of a nice little thing that was was put in.

And, and I guess the way that Henry is doing the some of these extensions, like the fold and whatnot, are really kind of J programs under the hood, that they are, they're implemented within J, within J, you know, the top of the interpreter, but they're, but the code is inaccessible to, you know, people running it.

So that's kind of interesting, and you're going back to your bootstrapping idea of what to do.

So, yeah, but I don't know.

- We talked to Henry about that.

Actually, we sort of devoted an episode to Fold to talk to him about that.

And you're right, right now, Fold is written in J, so it's not fast just because it's not written in C.

He's just waiting for more people to want to use it, and he'll write it in C, and then it'll be much quicker again.

But you know, I think that's… There's a certain stick in the leg.

It is a bit, although he said it wouldn't be hard to do, so I was kind of thinking, "Just get a few more people using it, and maybe we can push them into it.

" Yeah, but I mean, maybe more people would use it if it were faster.

Yeah.

Right now I think more people use, or people don't use it because they already have the other ways of using, of doing it.

They're going to do a suffix, a reverse scan or something like that.

That's how I've always done it.

I know what's going on.

I don't want to play with this new stuff.

Exactly.

I don't have to look it up.

reminded me in the array cast that it keeps, it maintains a count and so as the replacement for infinite power which, well yes, I now and then have to kill Jay Sessions when that goes for Ryan.

You know that's one thing it'll bring me to use it more.

The one that I find useful for is because the fold is a very common, very common thing in other in other functional languages.

It's in Haskell, it's in Lean, it's OCaml.

All these things have the fold, some form or another, and the way Henry has done the folds more closely matches that.

So it's easy to steal algorithms from other languages with the new JFold and then the scans and things like that.

So it definitely has its uses.

Yeah, from talking to them, the JFold actually includes a wide range of other languages' folds.

They all have their different version of it, but J actually, you can simulate most of them with what J's got as its fold.

Yeah, they're pretty handy.

The other thing is, have any of you played with the additions to the the the dyad and the state machine.

No, not yet.

There.

Because that that thing since it was created, it's always been kind of difficult to use.

And if you can get it to work, it's really, really fast and very useful.

But it's just a real pain to code that thing.

I mean, I think if people were redoing it now you do it more like a traditional grammar, something like a yak, or give it give it a series of phrases.

And that would be much easier for people to get on to.

And I suppose you could code that in the state machine.

But, but the I'll have to look at it.

But the last messages were people going on about these new states, make certain lots of little things a lot easier for people that have complained about over the years.

So I'm sort of curious to see how that plays out because every time I've tried to do a state machine, it's either really trivial and straightforward, or I just get lost and give up.

- The last time I played with a state machine, I was trying to do a Unicode code point interpreter.

And I got so it kind of worked, but it wasn't fast.

Like I could, using select statements and sort of the regular, I guess, declarative type of programming, I could get a quicker, and it was more consistent.

But one of the things I noticed in the emails about it was that it seems to address some of the empty string issues.

Yeah, that apparently been quite hurdle for a lot of people.

it comes up for a long time, you know, people clicking around with it, oh, if we could just not emit at this point, it would be so.

So I think it can do that now.

But so we'll see if this helps.

But, but there are some really handy ones out there, one of Rogers machines that basically done the J parsing, I use it in the little john system, because it handles incomplete quotes.

So if you're if you're analyzing code, the normal monadic case assumes it's all hunky dory, and it'll throw an exception if it isn't, which is not terribly handy.

The dyad version that will handle the incomplete and say, Oh, you missing a balance.

Well, good to know.

So like for code tools, some of these little adjustments are really, really handy.

So, but, but I always felt that, you know, that, that particular doing the dyadic case has been difficult to program.

It's, it's hard to sort of build these things.

I mean, once you get them, they're fine, but it's, it's difficult to do it.

It's sort of like, it's like that old joke about, you know, doing things with regular expressions.

Now you've got two problems.

You know, you should try to chat GPT, you know, ask it to do regular expressions.

It's pretty darn good at it.

You know, say give me a record.

It doesn't it what.

It's not the same syntax as the J regular expressions, but close enough.

So you just go in and they're ask it to do something and it'll come back.

Here it is.

Okay, great.

So do the same thing for the dyadic case.

Anyway, I got to go guys.

>> Thank you, John.

Great to see you.

>> See you later.

Bye-bye.

>> Okay.

Bye.

OK, so John reminded me of a project I briefly considered, which is grammar to state machine translator.

That would be a good, that's a good idea.

I'd use it.

Good idea for me.

Yeah.

Well, it's another project I haven't done yet.

It would be one where I think you'd, I know from the limited amount I've done with state machines, I'd learn a lot about the state machines by creating a grammar that talks to the state machines.

It's not the first time I've done something like that.

But I've used YACC quite a bit, well, Bison and Flex.

Well, it beats strips of paper and, you know, Turing machines.

Right.

Anyway, was there anything else.

I think I'm good, Bob.