Just don't write :wq by mistake

@RedwolfPrograms if you do, make sure to do ZZ, it's golfier

Just don't write ZQ by mistake

@RedwolfPrograms or :wq!

@pVCaecidiosporeadduced actually 3 bytes: Try it online!

@Bubbler how does that work?

That moment when you force save-and-quit somebody's life.

@cairdcoinheringaahing i want technoblade to be the 6th hunter

Jelly has a secret built-in for "generalized fibonacci" - define a recurrence f(n) = some function of f(n-1) and f(n-2), and compute the nth term given values of f(0) and f(1)

CMC: Become someones friend.

For vanilla fibonacci, the "some function" is simply +

@Bubbler why does that exist

Only Dennis knows...

nvm i am blind

Btw the symbol is overloaded with plain "iterate n times"

@Bubbler oh

an appropriate update to the dinoux readme

@pVCaecidiosporeadduced It's due to the way that ¡ handles dyadic links

It's completely unintentional that it's a generalised Fib calculator

When you run a dyad f n times, with a right argument, you have 2 options: keep the same right argument f(f(f(l, r), r), r), or you do what Jelly does and use the previous iteration as the left argument and the one before that as the right argument f(f(f(l, r), r), f(l, r))

Most of Jelly's repeated application quicks do that, except for the hooked T (loop until fixed point, return all results), which reuses the right argument each time

@pVCaecidiosporeadduced I've concluded that making a general-purpose golflang that beats all existing golflangs in 2021 is practically impossible. Maybe someone will do it anyway. But I've accepted that the someone won't be me.

So I'm aiming for the "fairly golfy, doesn't beat the top golflangs, but has a low barrier of entry and is relatively easy to use" niche.

I think the best way to make a general-purpose, winning language is to take an existing language (e.g. Jelly), identify its weaknesses then create a version of the language that addresses those weaknesses

Completely new and innovative golfing langs I think will be rare

@cairdcoinheringaahing That's boring :p

@DLosc The niche that I sort of like is "golfing languages that explore an obscure concept that could potentially be short sometimes", like Risky

Idea: A golfing language where the function of commands changes whether its index in the code is even or odd. The more common stuff would be the same regardless of its index, such as common arithmetic or string manipulation commands, and it could have a flag to switch between 0- or 1-indexing of the program. This would allow for 300+ 1-byte commands. For example: Ẋ might be cartesian product if it's the first command (source[0]), or dot product if it's the second command (source[1]).

I suspect you'd have a lot of no op padding

When you have a lot of no ops, you may be able to switch the indexing to golf it

there could also be a command to switch indexing on the fly, essentially swapping between even and odd functionality

@RedwolfPrograms Yeah, that's the other route: forget about being short all the time and focus on being short some of the time. I'm working on one of those, too (actually it's not a very obscure concept, just underutilized).

There's a subtle meta consideration, too: what types of challenges are common on this site? The top golflangs are going to be optimized for those types of challenges. For example, if we had more challenges involving rational numbers, more golflangs would undoubtedly have a rational number type built in.

I'm working on a language with 16 built-in types

So lots and lots of overloading

Wow

Also lots of typecasting, I'd guess?

Maybe, although you'd be surprised how little you can get away with

Just do what Vim does and store literally everything as text

@RedwolfPrograms I wouldn't be too surprised. Pip doesn't have any typecasting operators. (Although the desire to avoid typecasting is a big part of why I put strings and numbers in the same type. I'm still not sure whether that was a good decision or not.)

(Actually I guess you'd have to say ST and maybe RP are typecasting operators. But I don't know the last time I used them in a golf solution.)

Vyxal has I and S, to cast to number and string, respectively

I received permission from the original author to recreate their puzzle as a golf challenge; I'd love to do it justice, so I would love feedback from anyone that cares to give it.

@AaronMiller I completely forgot, there's also f to cast to a list (e.g. 1234 becomes ⟨1|2|3|4⟩ and waffles becomes ⟨`w`|`a`|`f`|`f`|`l`|`e`|`s`⟩)

All sounds pretty standard so far

yep

ḃ casts to a boolean

Ash didn't have any plain "to array" operator, you'd use different ones depending on type

For numbers it'd be "digits", and for strings it'd be "split by null string"

Which of those you choose doesn't have any impact on golfiness though, as long as you overload

Technically f is just flatten, but when used on numbers or strings it does list of digits/characters

Oh huh, that's smart. Making the type casting operators do something different when there'd be no change.

Ash sort of did that, actually

Split by null string became join by null string when you used it on an array

And digits was also its inverse when used on an array

We have ṅ to join on empty string

ḃ is a bit strange, though: Try it Online!

Wait... empty list is 1 and nonempty is 0?

@RedwolfPrograms Split in Pip affects each element when applied to a list: TIO

Join applies to lists directly, so if you want to join each element you have to map it explicitly

That's one of the fun/interesting/frustrating things about language design: I love finding nice patterns where operations can be designed orthogonally, but there are always corner cases that don't fit.

@DLosc yep, it's a bug

@pVCaecidiosporeadduced Why did you timeout your language's room for 12h...

That's why

Anyone know of a language where the current 'opcode' changes by a 1-bit shift through the code's bitstream, so all ops would be overlapping? Each shift could be seen as traversing a 4-connected graph of ops since you're losing a bit and gaining a bit, maybe that could be useful. I've hacked together a test interpreter here: github.com/mvirts/shift it only has a terminate operation and a test operation that prints some stuff.

@MVirts I don't think I quite understand what you mean, but are you thinking something kind of like this?

@AaronMiller Yes, very similar but sliding a window of 8 bits. Depending on how the operations are set up it could be a good golfing language.

@MVirts I've thought of something similar before, but never ended up implementing it

The problem I ran into is that you end up with a lot of commands that basically have to be used together, so to make something that's actually usable requires a ton of redundancy and no-ops

This has me thinking about maybe a stack-based language where every group of four commands consists of a push command, a monadic operation, a stack-manipulation command, and a dyadic operation in that order. Maybe some of the stack-manipulation slots could be used for flow control commands.

@RedwolfPrograms Let's see... integer, float, rational, complex, char, string, list, matrix, lazy list/generator, dictionary/map, set, multiset, function, regex, null... that's 15. How many of them did I get?

If you already have a list and char you probably don't need string.

Need, maybe not, but it sounds like Redwolf's making Super Overloading Language With All The Types, so I figured it'd have all of everything.

SOLWATT--nice acronym

16 isn't that many types.

@DLosc For number types, I had integer, rational, rational with imaginary part, and symbolic. I had char and string, function, null, dictionary, and lazy list as well. Where I differered was having lots of different specific list types, like one which was optimized for numeric operations

@WheatWizard For a golfing language where each of those types has a different overloaded operation it definitely is

@RedwolfPrograms I did totally forget about set though, that's a good one

Regexp too, although I usually try not to include those for portability reasons

Oh, I had bools

And a list type that would never vectorize

Plus a type of list which was multidimensional and guaranteed not to be ragged/have consistent dimensions, so that you could do all sorts of weird 3d/4d/Nd operations

Hooray!

@DLosc :( Please don't give up on Scala! It shouldn't be that hard, could you come to this room to discuss it more?

This message, specifically

Multiset union is the one where, e.g., [1, 2, 2, 4] U [1, 1, 8] would be [1, 1, 2, 2, 4, 8], right?

yes

(it's just result.count(x) = max(a.count(x), b.count(x)) i believe, and intersection is that but min)

@user In a bit, yeah. I have some things to wrap up first.

at least that's how i've observed it working and how i wrote the description for these two multiset operators on the jelly compendium :p

Actually, we could use the Scala room. Could you please unfreeze it, @hyper-neutrino?

@DLosc 👍 np

@DLosc 👍

@hyper-neutrino 👍

TNB's turned into a room of hitchhikers :P

@RedwolfPrograms Yep. Multisets are interesting because they have similarities to sets, lists, and dictionaries: a multiset can be described as 1) a set where elements can appear more than once, or 2) a list where the order doesn't matter, or 3) a mapping from each element to a positive integer.

So they're bags?

At first I'd written [1, 1, 1, 2, 2, 4, 8] and it took me 4 minutes and 51 seconds to realize that's just concatenation :p

(where the order doesn't matter, at least)

@RedwolfPrograms If your doing a golfing language why limit yourself to 16 types?

I didn't that was just how many I'd come up with

Although coming up with more than 256 overloads for every dyad (with some dupes, tbf) sounds pretty time consuming :p

You can probably do a lot of aggressive polymorphism.

Which is why it might be a better idea not to have string as it's own type.

Pretty much anything you want to do with a list you also whant to do with a string and to a lesser extent vice versa.

Eh, not so sure about that

Cumulative sum of a string? Sum? Product?

And, for the other direction, splitting a list of numbers by newlines? Title casing it?

Sum and product are not really going to be very useful for most lists are they?

I would overload those based on the constituent type not the list itself.

That assumes the lists are overloaded by their constituent type, which they weren't

I'm not sure what you mean.

Are you saying you can only have lists of integers?

No, they just aren't overloaded by the type they hold

Although that could be a good idea

It'd get a bit weird for arrays with mixes of types though

How can a list be overloaded by a type?

I would just say "sum is a fold with the + dyad", that works on mixed type lists just fine too.

@WheatWizard I mean the operators aren't overloaded to handle lists of different types differently

Ah ok. Well I think my suggestion solves that problem entirely.

For some stuff, but it's harder to do that with, e.g., split by newlines or title case

Yeah that's why I said vice versa is to a lesser extent.

The problem for me is that If I come up with 256 good operations on lists I also have 256 good operations on strings so I don't have space to fill in the extra bits.

There's quite a lot of array operations that make no sense on strings imo

If you feel that way then I would suggest ditching the char type instead.

The point of my language is to have unreasonably many types, so I don't really see a reason to :p

Really, the issue I see is that there is no meaningful distinction between list of chars and strings. I think either the char or the string type ought to go.

There are plenty of types that you could add though!

@WheatWizard Well, there is no "list of chars" type

Regular lists would be intended to be used only really when the type could vary

Yes but having list and chars implies there are lists of chars.

Not really

Why not? Of the three options to get rid of lists of chars seems to be univerally the poorest choice.

But there is no "list of chars"

The only two options are get rid of chars or get rid of lists

Or make it so lists can't hold chars :p

The three options are get rid of strings, get rid of chars, or make lists unable to hold chars. Of which the third is by far the worst.

I don't see why chars can't exist without implying lists of chars should be used

It'd be a convenient type to return from things like "nth character in string"

My point is that they are useless. That is the whole point.

I disagree though

What?

You just claimed it 2 seconds ago.

And now you disagree?

When?

@RedwolfPrograms Here.

Oh, I thought you were saying chars themselves are useless

I think a list of chars and a string have two very different purposes: one's just a list of characters, while one specifically implies that they go together to form one string of text.

My point is that with the three types present there is a redundancy in the design. There are three ways to resolve it, 1) replacing chars with strings 2) replacing strings with lists of chars 3) preventing lists from holdings chars. The third is unambiguously the worst, the other two seem just fine.

The redundancy is intentional

If the only issue with having all three is redundancy, I see no issue

@RedwolfPrograms For the design of a normal language that is very useful. I fail to see how this redundancy is helpful for a golfing language.

You can have overloads based on the context in which it's being used

(and by "golfing language" I mean more like "an experimental/demonstration golfing language like Risky")

@RedwolfPrograms For example, sorting a list of characters could make sense. But sorting the characters in a string seems like a very rare operation to need.

In my experience attempting to design a golfing language with the same gimmick a couple of years ago, these sorts of redundancies just waste time for me, and while they may at some point potentially have some small payoff until you've filled in every gap they just make it less effective.

Your time is better spent on actual novel types then on slight variations of the same few types.

Lists of characters wasn't even something I was considering when I came up with adding a character type

If it's not useful to put chars in a list, just don't put them in a list

If it's not useful to put them in a list then that's a design flaw.

Not really imo

If it's necessary to have that option in order to enable a different somewhat useful feature

What would be an operation on a char that would be useful?

... that wouldn't be equally useful as an operation on strings.

Oh, here's an idea for a situation where strings and lists of chars are a good distinction to have:

Conditions

E.g., "is alphanumeric" on a list of chars would vectorize, while on strings it would check if all of the characters are alohanumeric

What do you mean by vectorize?

@RedwolfPrograms "Alohanumeric"...when a number wants to greet you in hawaian

If you have a string type, why have a separate char type? Why not do what Python and JS do and make those singleton chars strings too?

@WheatWizard It would map the function to each char, no matter how deeply the list is nested

@WheatWizard A list of booleans, so ['a', '+', '2'] would be [true, false, true]

This is what I have been suggesting.

@RedwolfPrograms That's an awfully strange word for "map".

It's not just map, it can go as deep as you need it to

"vectorize" is a super common term for that from what I've heard

At least for golfing languages

Doesn't make it not strange :P

e.g. [[[['a', '+', '2']]]] would be [[[[true, false, true]]]]

@WheatWizard Everything's strange if you've never encountered it before

@WheatWizard if it's good enough for Dennis and Adnan, it's good enough for me

@user That's definitely a false claim

@user Except SQL which gets stranger the more you encounter it

@WheatWizard Eh, not surprising, considering the fact that all generalizations are false :P

@user That

's still a map.

Oh

This is like arguing about map vs. dictionary, they're just two words for basically the same thing :p

(Though map and map are not :p)

Yeah but one makes intuitive sense from first principles and the other has an intuitive meaning that misleads you.

If I see "vectorize" my first thought is "makes it a vector"

I didn't come up with it :p

Doesn't much matter to me who came up with it.

Anyway. I have to go to sleep. My point is just from experience it is far more valuable to have a large number diverse types than an equal number of highly similar types.

o/

¯\_(ツ)_/¯ "map" to me sounds like it only applies to a depth of 1. I wouldn't expect map abs to turn [[-1, 0], [[-3]]] into [[1, 0], [[3]]]

o/

"deepmap" sounds more intuitive

@user TBF "vectorize" does too

Does what?

And the way I implement it, it is (but it's recursive)

@user only applies to a depth of 1

Wait really?

Then what do you call the recursive/deep map/vectorizing?

I also call it vectorizing because I don't like myself

Same

:P

Someday I'm adding a map type to a language, which is a 2d representation of geographic features

So I can have a map from inputs to maps, and map that over an array

Wolfram Alpha probably beat you to it :P

Anyone else combine the first two syllables in their heads and abbreviate "Wolfram Alpha" to "Walf"?

@RedwolfPrograms Me if I saw a person tied to train tracks: ZZzzz...

@RedwolfPrograms Why not just wolf lol

Your name is literally Redwolf, have you no loyalty t o your species?

Are there any shells out there that use AI to understand human-sounding text?

It'd also make scripting fun

That sounds absolutely horrible

Actually, are there any programming languages that use AI to understand human-sounding instructions?

Anything's an AI if you're loose enough with "intelligence"'s definition

@RedwolfPrograms that just sounds like Codex with extra steps