Uiua creator here. I'm glad Conor is enjoying the language so much! This is a nice solution to a LeetCode-type problem, which Uiua is very good for, but it can do much more! The website's editor has built-in functionality for generating audio and images from arrays. The native interpreter has support for file IO, TCP sockets, and more, so you can write Real Programs™. Have fun!
@@user-ui8my9zs7o The native interpreter has a built-in language server, so any editor with a language client should be able to hook into it. I know some people have gotten emacs and neovim set up, in their own configs at least.
I have been playing with J for over 10 years, APL for 5 or 6 years, and I started to check out BQN, but the symbols threw me subjectively. I love stack languages, so now I am jumping on uiua. The audio/pixel stuff grabbed me immediately, since I play with generative sound design, and this looks very promising. Amazing work!!
I solved the sum_of_squares using Excel's LAMBDA functions like this: =LAMBDA(xs, LET( f, phi( b( is_zero, phi( tally, modulo, bbb(add_1,TR,range,tally) ) ), mult, square ), res, SUM(f(xs)), res )) Excel is kind of an array language with array addressing like A1#.
I guess that once you give names to your little functions you can divide a big problem in its parts much like in procedural languages. I don't see really a big difference.
I love the concept of using the multiplication by zero with the mask as a bitwise AND operation to nuke unwanted data. Really appeals to the Computer Engineer in me. It also mirrors how you'd represent working with a Logical AND in Boolean Algebra, as a multiplication operation. I wish I could've found this appreciation for more purer forms of math while I was still a student, but this'll do in lieu of a time machine.
I believe it could be really powerful if accelerated on GPU. Imagine writing a few lines in Uiua instead of hundreds of lines in OpenCL and getting the same or even better performance
In your Function Composition in Programming Languages talk you said you won't be talking about Forth or Joy. Well I really want to hear your take on both and what you think they bring to the table that many are underestimating, including array languages.
this whole combination (given below) finally made me understand what was being done here: this sound suuuper obvious, to the point of being dumb. but what can i say, i was lost in glyphs & concepts & combinator names & didn't really catch what the output was corresponding to. * function (fxn) is being defined up top - those operators/combinators will work on the parameter(s) * parameters in definition: can be formal, or in case of tacit, be implicit. * thereafter, fxn is called with actual parameters (the input array) being supplied already * result shown live at bottom as the function definition is being updated THINGS which helped: * 1:532:02 _"These are 2 test cases, Answer to the first is 21, to the second is 63"_ * answer written in source, * the "Show" keyword * Reading "Friendly glyphs" section of uiua website * 5:175:32 _"This sol is mentioning our args: x, & x again"_ * 8:248:42 _"in uiua pad ... we gonna call length:_ returns 6; _then range:_ returns [0..5] _"_
I would love to see one of these doing the long form of an established algorithm with many use cases like Fourier transforms or linear regression. These videos have already been wonderful! I've never seen matrix languages before and I'm so happy that you break it down into a way I can understand.
The problem with stack-orientation is that in long expressions it's an additional mental load to remember stack state in every position. I much prefer using binds to extract calculations into named variables.
Yea stacked language is more procedural than declarative, which makes understanding the solution from a top-level difficult, but it could be that I have not obtained the ability to decipher a stackful solution without stepping through. However, it’s really good for visualization
Actually I think Uiua is great. Yes, there's a stack, but you can look at it abstractly as a way to define the computational graph under the algorithms (i.e. functions). It is in my opinion more clear than using many combinators.
Connor; as much as you love your combinators, I think you've gone a bit too far into the deep end of combinator speak. I have no idea what a sigma combinator does, so using more laymany terms would probably be better for people watching your videos who aren't as far into the combinator deep end as you are
Agreed. It's a niche academic area akin to talking about lambda calculus. It's more likely that a viewer has little background in combinators than someone who is an expert at them. It would be great to briefly explain what the combinator does after he mentions it. At least we would be able to catch on with it.
Point free doesn't refer to some symbol, it refers to points in the argument domain, i.e. individual values. So instead of talking about how to transform one point x into another f x, we talk of how the space itself is transformed, equally applicable to all points; f, which is a function.
I'm not the language designer, but I think this has to do with the visual approach to reading and typing glyphs. ◿ to me represents a partial graph of the modulus function. For y=(x mod a), it rises linearly until y reaches a and then jumps down to zero again. % is not a great candidate for modulo, because you have /, \ and ∧ for reduce, scan and fold, which makes clear they are very related and even visualises the difference in their application. For the numerical operators, you don't have * and / as in other languages, but × and ÷, which I would argue is actually easier to read for anyone not used to programming. But now the visual relationship you have in other languages between / for division and % for the remainder is broken, so considering a completely new glyph makes sense. % also has the issue of being visually bigger and thus appearing more significant than the other numeric operators, which it isn't.
have you seen the talk (here on youtube) concatenative programming: from ivory to metal? i think you’d love it (topics: stack-based languages as the combinator calculus, implementing stuff fast, linear types, a little apl from backus’s turing speech, continuations)
Yeah that talk is what he needs to see and why I think a lot more should be interested in what concatenative programming as described in that talk can bring to other paradigms, including array languages. Maybe have Jon Purdy invited on Arraycast since he is familiar with programming language design and could update us on what other things he was not able to cover in that talk that we might be missing out.
Interesting, so there is no need to learn tons of combinator patterns to use it. I'm sold on this. I'll probably learn about combinators one of these decades when I find the spare time to do so 😂
I know this video is uber old comparatively but I wanted to point out that in the BQN solution, you theoretically could’ve also used an after instead of right tack multiplies.. it doesn’t end up saving characters but I do love the symmetry of having both before and after (or Σ and S) in the same solution
I wonder how this effects pronouncability? As in, generally in apl, you can read from left to right to describe algorithms in a human inderstandble form. The blank of the blank of the blank....not sure that works when you have to track the stack.
I'm not sure, to me it's easier to talk about it in blocks of pseudocode from right to left: Duplicate the input, get length, duplicate length, create a range, add one, modulus length, check if 0, multiply input with that mask, power of 2, reduce add. Reading from left to right it would be: The sum reduction of the list of squares of the result of applying a mask of the elements where modulus of the length of the input over the index of each element is 0, but that doesn't quite fit the evaluation order or the naming of the operations.
@@red13emerald the big issues is that if you get a large chain of blocks and want to understand them, you have to track the entire stack in your head. Also, normal array languages tend to be quite readable once you learn the rules. But I do agree that this is probably easier to understand without learning anything new. Programmers already understand stacks and don't have to learn trains.
@@red13emerald I'm definitely not convinced. Tracking a stack of values is much more overhead than tracking a train (only 2 live values at a time) or named variables.
you are pretty much smashing keywords in your comment, could you do it, yes, does it make sense, probably not for many reasons. 1) you wouldn't be using tons of good libraries that already exist in many languages. 2) the community of people that could contribute would be very small 3) a database is a lot more than just computation, you'd also need to interact with the os, manage memory, etc. 4) there are definitely a whole load of other reasons. anyway, that would not be practical to do at all, and anytthing that can be done with an array language can be done without, that's quite a lot out of their scope, they can be very useful for numerical work but a vector database is a lot more than that.
Unicode, and a well-designed font. While you can copy uiua code to basically anywhere (for example: ▽¬⍜⇌\×∊,) and it will display "correctly", the website specifically recommends the font "DejaVu Sans Mono", which the code looks a lot better in.
11:43 > _"no need to learn combinators"_ yeah - what more, i would say that the stack operations: duplicate, flip, etc make communicating about (& hence teaching & learning) the combinators far more easiers
I truly can’t thank you enough for all your videos. You’ve seriously made me so excited about learning different programming languages & paradigms. Out of curiosity, will you be at the next CPP North? I would love to see one of your talks in person !!!
Glad that you are as excited as I am! I hope to be there but won't know until some time in 2024. I am hoping to present on my research that I have been working on at NVIDIA at some point in 2024 at some conference. Whether that is at @cppnorth or another conference is TBD
Uiua creator here.
I'm glad Conor is enjoying the language so much!
This is a nice solution to a LeetCode-type problem, which Uiua is very good for, but it can do much more!
The website's editor has built-in functionality for generating audio and images from arrays.
The native interpreter has support for file IO, TCP sockets, and more, so you can write Real Programs™.
Have fun!
What's your plan for editor support. I saw you have vs code support but what about emacs?
@@user-ui8my9zs7o The native interpreter has a built-in language server, so any editor with a language client should be able to hook into it.
I know some people have gotten emacs and neovim set up, in their own configs at least.
Loving it, where can I find examples of file i/o?
A mode that switches the symbols to words would be useful in the playground. Hovering is a little cumbersome
@@daviidon You can go to the site's documentation page and scroll down to the system functions. Hover them for their names.
The stack is definitely the killer feature. This is the first array language that "clicked" for me
Yeah, I feel the same. The stack makes it so much easier to understand what's going on an where the data lives.
I have been playing with J for over 10 years, APL for 5 or 6 years, and I started to check out BQN, but the symbols threw me subjectively. I love stack languages, so now I am jumping on uiua. The audio/pixel stuff grabbed me immediately, since I play with generative sound design, and this looks very promising. Amazing work!!
Keep the Uiua videos coming!
I solved the sum_of_squares using Excel's LAMBDA functions like this:
=LAMBDA(xs, LET( f, phi( b( is_zero, phi( tally, modulo, bbb(add_1,TR,range,tally) ) ), mult, square ), res, SUM(f(xs)), res ))
Excel is kind of an array language with array addressing like A1#.
All of these videos make these array languages look interesting but also make it look like they're only toys for solving little code problems.
I guess that once you give names to your little functions you can divide a big problem in its parts much like in procedural languages. I don't see really a big difference.
moar uiua please ! 😍 (thank you for your videos, they are perfect for my little routine of watching youtube before going to bed ^^)
I found your other BQN vs Uiua video and instantly fell in love with Uiua
I love the concept of using the multiplication by zero with the mask as a bitwise AND operation to nuke unwanted data. Really appeals to the Computer Engineer in me.
It also mirrors how you'd represent working with a Logical AND in Boolean Algebra, as a multiplication operation. I wish I could've found this appreciation for more purer forms of math while I was still a student, but this'll do in lieu of a time machine.
Looks insanely powerful and equally insanely hard to apply to real problems, even abstract like comp programming or coding interviews
I believe it could be really powerful if accelerated on GPU. Imagine writing a few lines in Uiua instead of hundreds of lines in OpenCL and getting the same or even better performance
Episode one got me started with Uiua. I will master this language.
uiua is ngl so much more intuitive 😂 love the new content ❤
In your Function Composition in Programming Languages talk you said you won't be talking about Forth or Joy.
Well I really want to hear your take on both and what you think they bring to the table that many are underestimating, including array languages.
this whole combination (given below) finally made me understand what was being done here:
this sound suuuper obvious, to the point of being dumb. but what can i say, i was lost in glyphs & concepts & combinator names & didn't really catch what the output was corresponding to.
* function (fxn) is being defined up top - those operators/combinators will work on the parameter(s)
* parameters in definition: can be formal, or in case of tacit, be implicit.
* thereafter, fxn is called with actual parameters (the input array) being supplied already
* result shown live at bottom as the function definition is being updated
THINGS which helped:
* 1:53 2:02 _"These are 2 test cases, Answer to the first is 21, to the second is 63"_
* answer written in source,
* the "Show" keyword
* Reading "Friendly glyphs" section of uiua website
* 5:17 5:32 _"This sol is mentioning our args: x, & x again"_
* 8:24 8:42 _"in uiua pad ... we gonna call length:_ returns 6; _then range:_ returns [0..5] _"_
I would love to see one of these doing the long form of an established algorithm with many use cases like Fourier transforms or linear regression.
These videos have already been wonderful!
I've never seen matrix languages before and I'm so happy that you break it down into a way I can understand.
Stack, BASED
Understanable sir.
Would you make a video comparing J, APL, BQN and Uiua?
I will definitely do that in the future. Kind of what I was trying to do with the "revisiting" the APL vs J vs BQN vs etc video.
@@code_report Wow that's great!
I will definitely be waiting
The problem with stack-orientation is that in long expressions it's an additional mental load to remember stack state in every position. I much prefer using binds to extract calculations into named variables.
Yea stacked language is more procedural than declarative, which makes understanding the solution from a top-level difficult, but it could be that I have not obtained the ability to decipher a stackful solution without stepping through.
However, it’s really good for visualization
I guess it is nice that Uiua supports both stack-based programming and bindings. E.g. write with bindings first, then (possibly) compress.
Actually I think Uiua is great. Yes, there's a stack, but you can look at it abstractly as a way to define the computational graph under the algorithms (i.e. functions). It is in my opinion more clear than using many combinators.
Connor; as much as you love your combinators, I think you've gone a bit too far into the deep end of combinator speak. I have no idea what a sigma combinator does, so using more laymany terms would probably be better for people watching your videos who aren't as far into the combinator deep end as you are
Agreed. It's a niche academic area akin to talking about lambda calculus. It's more likely that a viewer has little background in combinators than someone who is an expert at them. It would be great to briefly explain what the combinator does after he mentions it. At least we would be able to catch on with it.
the combinators are my favourite part!
but Uiua is objectively brilliant
Point free doesn't refer to some symbol, it refers to points in the argument domain, i.e. individual values. So instead of talking about how to transform one point x into another f x, we talk of how the space itself is transformed, equally applicable to all points; f, which is a function.
9:34 why ain't the mod given the `%` glyph?
I'm not the language designer, but I think this has to do with the visual approach to reading and typing glyphs.
◿ to me represents a partial graph of the modulus function. For y=(x mod a), it rises linearly until y reaches a and then jumps down to zero again. % is not a great candidate for modulo, because you have /, \ and ∧ for reduce, scan and fold, which makes clear they are very related and even visualises the difference in their application. For the numerical operators, you don't have * and / as in other languages, but × and ÷, which I would argue is actually easier to read for anyone not used to programming. But now the visual relationship you have in other languages between / for division and % for the remainder is broken, so considering a completely new glyph makes sense.
% also has the issue of being visually bigger and thus appearing more significant than the other numeric operators, which it isn't.
have you seen the talk (here on youtube) concatenative programming: from ivory to metal? i think you’d love it (topics: stack-based languages as the combinator calculus, implementing stuff fast, linear types, a little apl from backus’s turing speech, continuations)
Yeah that talk is what he needs to see and why I think a lot more should be interested in what concatenative programming as described in that talk can bring to other paradigms, including array languages.
Maybe have Jon Purdy invited on Arraycast since he is familiar with programming language design and could update us on what other things he was not able to cover in that talk that we might be missing out.
Interesting, so there is no need to learn tons of combinator patterns to use it. I'm sold on this.
I'll probably learn about combinators one of these decades when I find the spare time to do so 😂
I wonder which language will be the favorite one
Loving Uiua 👍🏻
I know this video is uber old comparatively but I wanted to point out that in the BQN solution, you theoretically could’ve also used an after instead of right tack multiplies.. it doesn’t end up saving characters but I do love the symmetry of having both before and after (or Σ and S) in the same solution
8:00, here you had 18, but here 8:23, 19. I didn't get why 7 was approved.
Is UIUA compiled or interpreted? How is its performance compared to other programming languages?
I wonder how this effects pronouncability? As in, generally in apl, you can read from left to right to describe algorithms in a human inderstandble form. The blank of the blank of the blank....not sure that works when you have to track the stack.
I'm not sure, to me it's easier to talk about it in blocks of pseudocode from right to left:
Duplicate the input, get length, duplicate length, create a range, add one, modulus length, check if 0, multiply input with that mask, power of 2, reduce add.
Reading from left to right it would be:
The sum reduction of the list of squares of the result of applying a mask of the elements where modulus of the length of the input over the index of each element is 0, but that doesn't quite fit the evaluation order or the naming of the operations.
@@red13emerald the big issues is that if you get a large chain of blocks and want to understand them, you have to track the entire stack in your head.
Also, normal array languages tend to be quite readable once you learn the rules. But I do agree that this is probably easier to understand without learning anything new. Programmers already understand stacks and don't have to learn trains.
So is this essentially a battle of combinators/trains vs stack for tacit and operation ordering?
There is no battle, stack-based is easier to write, read and reason about and thus 100% better in every regard 😇
@@red13emerald I'm definitely not convinced. Tracking a stack of values is much more overhead than tracking a train (only 2 live values at a time) or named variables.
good forth programmers keep the stack shallow within their word definitions.
Would an array language be useful for developing vector databases?
you are pretty much smashing keywords in your comment, could you do it, yes, does it make sense, probably not for many reasons.
1) you wouldn't be using tons of good libraries that already exist in many languages.
2) the community of people that could contribute would be very small
3) a database is a lot more than just computation, you'd also need to interact with the os, manage memory, etc.
4) there are definitely a whole load of other reasons.
anyway, that would not be practical to do at all, and anytthing that can be done with an array language can be done without, that's quite a lot out of their scope, they can be very useful for numerical work but a vector database is a lot more than that.
How do they make these beautiful glyphs?
Unicode, and a well-designed font. While you can copy uiua code to basically anywhere (for example: ▽¬⍜⇌\×∊,) and it will display "correctly", the website specifically recommends the font "DejaVu Sans Mono", which the code looks a lot better in.
Man, how do you even type these symbols💀
we wa
Chesus Christ!
haskell :
sumOfSquares = length >>= flip execState 0 .* g
where
g = flip zipWithM [1..] . f
f n i a = when (n `mod` i == 0) $ modify (+ a * a)
or:
sumOfSquares = length >>= getSum .* f
where
f n =
ifoldMap $ \i a -> if n `mod` (i + 1) == 0
then Sum (a * a)
else mempty
11:43 > _"no need to learn combinators"_
yeah - what more, i would say that the stack operations: duplicate, flip, etc make communicating about (& hence teaching & learning) the combinators far more easiers
I truly can’t thank you enough for all your videos. You’ve seriously made me so excited about learning different programming languages & paradigms. Out of curiosity, will you be at the next CPP North? I would love to see one of your talks in person !!!
Glad that you are as excited as I am! I hope to be there but won't know until some time in 2024. I am hoping to present on my research that I have been working on at NVIDIA at some point in 2024 at some conference. Whether that is at @cppnorth or another conference is TBD
I feel like we're seeing a new chapter in The Life of Conor Hoekstra where stack-based languages are now the new friend. :D
"It does make it hard to read"
yeah you're telling me, lol
I guess in uiua you can replace "=0" with "not". Thanks for your wonderful videos.
astonishing