The Uiua Programming Language Caught Me By Surprise
Вставка
- Опубліковано 5 жов 2023
- A brief look at the Uiua programming language, followed by some reflection on aspects of it that mainstream imperative languages might benefit from.
Camera: Canon EOS R5 amzn.to/3CCrxzl
Monitor: Dell U4914DW 49in amzn.to/3MJV1jx
SSD for Video Editing: VectoTech Rapid 8TB amzn.to/3hXz9TM
Microphone 1: Rode NT1-A amzn.to/3vWM4gL
Microphone 2: Seinheiser 416 amzn.to/3Fkti60
Microphone Interface: Focusrite Clarett+ 2Pre amzn.to/3J5dy7S
Tripod: JOBY GorillaPod 5K amzn.to/3JaPxMA
Mouse: Razer DeathAdder amzn.to/3J9fYCf
Computer: 2021 Macbook Pro amzn.to/3J7FXtW
Lens 1: Canon RF50mm F 1.2L USM amzn.to/3qeJrX6
Lens 2: Canon RF24mm F1.8 Macro is STM Lens amzn.to/3UUs1bB
Caffeine: High Brew Cold Brew Coffee amzn.to/3hXyx0q
More Caffeine: Monster Energy Juice, Pipeline Punch amzn.to/3Czmfox
Building A Second Brain book: amzn.to/3cIShWf
Keyboards
Redragon K552 - amzn.to/3oNtpD7
Keychron Q1 - amzn.to/3YkJNrB
Keebio Iris - keeb.io/collections/iris-spli...
Purple Gradient Keycaps on Iris - amzn.to/3UZq93f
Corne v3 - shop.beekeeb.com/product/pre-...
Apollo themed keycaps on Corne - amzn.to/3IXKPUc
Chocofi - shop.beekeeb.com/product/pres...
Piantor - shop.beekeeb.com/product/pre-...
Kinesis Advantage360 Professional - amzn.to/3Ce5zUf
Glove80 - www.moergo.com/collections/gl... - Наука та технологія
Glyphs make sense when they're universal or well understood by the target audience. Logical operators or pi are good symbols, but these aren't popular because look at your keyboard... I don't have a pi symbol on mine (I guess would be different on a Cyrillic or Greek language keyboard.) Using glyphs that don't appear on keyboards becomes an input bottleneck. Also trying to read and understand an esoteric symbol versus a word becomes difficult.
I was thinking the same. It's definitely not going to work.
The old array language solution was backslash-ascii like \+ or \x but Uiua's solution is pretty good where you type the name of the function and it converts to the symbol on run
Also with the glyphs they're not much slower to learn than learning a std library's functions that you haven't seen in other languages before and once you know it its much faster to read, at least for me it has been
I find the biggest barrier is just the feeling of seeing so much unfamiliar junk at once that feels like you can't guess the meaning easily
this could open a market for new keyboards models for programmers to let you add more keys and customize them, you can see a lot of glyph usage in the mathmatical field too
Yes, it would create a readability issue.
Confusing that everything is written in reverse.
1 1 + make sense
+ 1 1 doesn't for a stack based language.
I think glyph usage is more common in any math or algorithm heavy paradigm. A small set of functions are used repeatedly because they compose well together.
You could probably write tons of rust programs that make use of almost none of these glyphs, other than the basic ones for fn or let, because there are a lot of rust programs that just might not need to do any mapping or filtering and instead just call out to different libraries.
That being said, I see no reason our current symbology for basic math notation couldn't be expanded to include what we now view as very common functions. If someone could actually standardize a symbology for these glyphs then I think we'd all find reading a map glyph just as easy as reading the addition symbol.
agree - is there a good reason for them to be specific to "math / algorithm heavy" paradigms though? It seems like they would provide the same benefits anywhere there is some set of frequently used functions
Agree that even with a glyph vocabulary there would likely be programs that don't make heavy use of them, because they are doing something very specific. But the concept could apply to a much wider set of functionality than map / filter etc - think of all the commonly used constructs in Rust - Option, Box, Arc, clone, etc
@@codetothemoon Good points. I guess the ? operator in rust is an example of how they're already providing a frequent function with a symbol. If that was an actual function call instead of a symbol it would probably get annoying quickly. I guess language creators stop doing that when they run out of useful ascii symbols. Delving into UTF8 is a bigger commitment.
Developers would need their users to have IDEs that support inputting UTF8. It becomes a hassle to make quick changes from anywhere other than an IDE with proper support.
Ken Iverson proposed a very similar idea back in the 50's in a paper called "Notation as a Tool of Thought" which described using glyphs or notation to represent algorithms. This lead to a language called APL which is the very first array language (or Iversonian language) which used these glyphs. Array languages also express many things using combinators (eg. the B or blackbird combinator which is the composition of two unary functions) which allow for building really expressive patterns. You can for instance create Conway's Game of Life in 3 lines of APL (ua-cam.com/video/pMslgySQ8nc/v-deo.html). Some other array languages are BQN, J, K and Q, with K even being used in financial systems as there is a powerful database available to the language (KDB+).
The question mark glyph is a seemingly universally praised part of my favorite part of rust, its error handling.
The stack thing is very forth-ish, a family of languages I've been meaning to fiddle around with for a while.
You made Rust even more difficult to understand? That’s an achievement! 👏🏼 😅
I think having the option to replace keywords with a glyph would be kinda neat, without being forced to learn them all
LOL - I suppose it is 😎
Re: the option to replace keywords with glyphs, I agree I think there might be something there...
@@codetothemoon picture this…
The relatively simple syntax of Typescript, without the compilation to JS. Compiles to native binaries, but remains high level.
Could remain GC’d or employ ownership/borrowing. Throw in some glyphs while we are at it.
The closest I have come to ticking some of the boxes are Grain (but it compiles to WASM, which can get complicated for backend) & Haxe (cross-compiles to JS, C++, Python etc)
Either I am not looking hard enough, or such a language is yet to exist..
People will suggest replacements such as Rust, Go or even Python, but these are really far removed from TS, in their own ways & Rust will look attractive for providing the biggest performance advantage (likely the a main reason for wanting to switch), but with an enormous learning curve.
@@everyhandletaken The closest you will come is Nim.
- Statically typed but has type inference.
- Compiles to tiny dependency-free executables
- Compiles to C, C++, Objective C, and JS so runs on all platforms.
- Has performance comparable to C (it compiles to C so..).
- Has automatic memory management so you do not have to manage memory unless you want to.
- Metaprogramming that is at a level rarely seen in any programming language so there is literally nothing you can't do in Nim.
It's the closest to the language I have spent 35 years looking for. I absolutely love it and have pretty much switched 100% to Nim.
@@ViaConDias if it weren’t for whitespace overly curly, I would probably be there, I think
@@everyhandletaken You get used to it really quick. I switch between Nim, TS, Python, C, JS, GDScript, and more some times several of them in the same day and I don't even notice it anymore. Only I forget the f'ing ; that I hate with a passion 🙂
this video took a much better turn than I expected! Really cool to hear your ideas about programming.
It's funny that I was interested in uuia and "next gen" keyboards and for some reason the yt algorithm just recommended those videos, didn't even know it was you in both of them. Really cool stuff, thanks.
thanks! I'm often hesitant to give opinions, thinking folks might prefer more objective, matter-of-fact type content. I was definitely sticking my neck out a bit with this one, and I'm happy that it's being well received by many.
Re: these disparate topics, I've found that like minded folks are often interested in both 😎
Uiua is awesome, there's something really comfy and approachable about it (compared to other array languages, IMO). And the multimedia capabilities make it extra fun!
Agree 💯
The website is immaculate as far as intros to array languages go
As a non-native english speaker, it's like we are already using glyphs. If you add modern IDE functionality, I think this makes a lot of sense.
hats off to you and all non-native english speakers in general - I'm a native speaker and I feel like this industry is challenging - I can only imagine the added challenge of learning a second language...
Re: IDE functionality, yeah I think this is the only approach that would make something like this palatable. So the language would have non-glyph words for all functionality, but those could be visually replaced with glyphs as the developer learns them.
Learning english is effectively a necessity to even begin with IT stuff. Most of technologies are made and described in english. Of course, there are some localized resources and documentation depending on a particular language. But if you want to have relevant information and international communication, you practically have no choice.
Machine translation is a thing, but quality is mostly very poor.
very much agree here. arguably glyphs could make programming easier for non-english speakers.
This is a super interesting take. But if the documentation for what the glyphs are and how they work is still predominantly in English, won't you still have the same problem?
Yes, using Glyphs for language independent code isn't such a bad idea...
One thing I've pondered creating a language that was intended to be drawn instead of typed, it would be mostly glyphs for language keywords, and flow control symbology would end up having you physically draw out the branching paths and then reconnect.
Wow, really interesting idea. I think there's a large set of people who would never consider learning to code in its current form, but would be happy to learn the drawn language you're proposing
reminds me of visual scripting systems in a lot of game engines
In Haskell you can overload common operators or write your own so I used the dot asci character to represent the dot product and x ascii to represent the cross product
I think the ability to use glyphs on operators is pretty useful
10:49
Middle dot · and multiplication sign × are not ASCII, though they are in Latin-1 (ISO 8859-1).
Scala has this feature as well, it also allows you to treat methods with a single parameter as an operator. So you can both use methods with names as operators "a add b" as well write your own operators as well as overload the regular operators. So "a…b" could be written to generate a range, or the dot/cross products by using the correct mathematics symbol.
It's a shame it's so locked into JVM, it's a very elegant language in many ways.
This feels like one of those ideas that someone thought of and wrote off as impractical a few decades ago and is probably worth re-exploring. With the current rust tooling, most people have some sort of key-bind for tuning on and off inline type information, a similar mechanism could work pretty well with this (where you can toggle on and off the full "words based" version of the code).
thanks, glad you think so as well! yeah, i think the ability to switch it on and off as desired is pretty key
Being already a rust built language making a macro for it doesn't seem very out of reach to me
This is literally an idea someone thought of and made a few decades ago. Called APL. And it was an amazing idea and had great success. It lived on in the background and is now popping back up again trough this language and BQN. I have some videos on BQN on my channel if you're interested 😄. The array language world is super cool.
@@davidzwitser Both APL and BQN are mentioned in the video too
If I suppress my visceral reaction to reject something that feels so unfamiliar, then I think this actually makes a lot of sense! But I'd also be concerned simply by the sheer number of glyphs I'd want to have access to on my keyboard. Getting a programmable keyboard would become a requirement. Because it wouldn't be about "learning a second language" -- we're talking about learning an entire suit of keywords for a programming language with special semantic meaning. Golang has like 25 reserved keywords, Javascript around 60, Rust has 55ish... I'm not sure it's a good idea to add another 100 or so additional keywords to those languages (especially Golang, I'm not sure the user base could handle the complexity 😅).
As a go user I would love to have glyphs to just replace some of the builtin keywords so that it would be more concise. But it would be cool if you could also use glyphs/ any unicode character to name functions and variables as well. Then you could make some neat code.
Haskell uses some symbols like >>= and ++ which are easy to write with a normal keyboard, but is also concise when reading
I feel like that is a better option than non-keyboard glyphs
maybe so! I guess another approach (maybe a good compromise?) might be to add more "glyphs" that are different permutations of keys that are readily available on the keyboard
You can also have glyph-ing editors that turn character sequences into glyphs. But plain glyphs can be hard to type for a beginner.
The question you posed at the end reminds me of this article titled "using vim's conceal feature to make code more readable". You can configure your editor to display the glyphs as you want, which would be a way to bridge the gap between people who are more or less comfortable with glyphs.
Glyphs are popular in array languages due to Iverson's "Notation as a tool of thought" publication. This is due to wanting to make an "executable math" and taking inspiration from math notation. A good example of a non-array language that uses a lot of glyphs is Agda - once again a very math-inspired language.
Dyalog APL is a very rich and mature implementation of APL that evolved from Iverson's notation. The glyphs are easy to use - pick from the glyph bar or type a key combo like CTRL-i for iota, CTRL-r for rho, etc.. It's free for personal use and well worth the adventure. The online Mastering Dyalog APL will walk you through the whole language. There is even a Dylalg APL kernel for JupyterLab. I have Python, Julia and APL kernels installed.
The global stack concept is pretty intuitive if you have ever used an old school calculator with RPN (reverse polish notation)
Uiua is pretty nice. i enjoy stack based languages and array based languages so i come at it with a bias there. i mostly work on my own personal projects, so i use whatever is enjoyable at the time. i learned APL and wrote some things in it and then didn't touch any of it for years. surprisingly most of it was still comprehensible almost a decade later. i had no idea how to input it after all that time, but i could read most of it.
i think Uiua gets something right by replacing text with the symbols for input. i just naturally learned the symbols as i input them and saw them change. reading it back is fairly straight forward and some kind of hover info is enough to fish the forgotten glyphs back to the surface.
if symbols are chosen that intuitively indicate the function, then i think glyph based symbols could spread. it would reduce some of the cognitive load when looking back at old code.
coming into someone else's code when you aren't familiar with the glyphs is a nightmare though. trying make sense of what you're seeing feels like looking at a foreign language you've never been introduced to before. i think the ability to quickly swap the text for the glyphs individually, by selection and by file would go a long way to lessening that difficulty.
I like the idea of having glyphs as a visual alternate in an IDE or something. So you can have the more protable and more digestable to a non-expert, but then still have the convenience and clarity for someone who is well-versed in the glyphs.
The Coq ecosystem does this. It has long-form names for everything in the language, but most IDEs for it replace them with math symbols, i.e. ∀ instead of forall, etc etc. Typing the word collapses it into the letter, and pressing backspace in front of the letter makes "foral" show up again.
I am currently working on a language where you can define glyphs to replace any code construct you want. Actually you can define any extraneous syntax that you may want. It is still very experimental but I can send you a notice when I reach a first release candidate
According to youtube wisdom APL was first to introduce 'reduce' as a functional higher order operation. That's where the idea of map reduce came from originally.
I've been learning a little bit of Japanese lately and these glyphs immediately make me think of Kanji. If there were to be any language that uses glyphs, I'd think it would be most useful to use an actual word for it still.
For example, when I look up the word for 'reduce' in my dictionary, I see 削る (けずる); this is actually a transitive verb, but the kanji itself 削 has the meaning (plane, sharpen, wittle, pare, shave).
lol, make a uiua or apl or bqn translation with kanji, that would be funny
I really like the idea of glyphs for the reduced visual clutter. So in other words I guess I like the visual esthetic off glyphs. Only downside is I think it needs to be made in a way that make sense on a common keyboard somehow, so that it can be written fast
Interesting video!
What I really missed was a comparison with APL (that you mentioned). What, if any, would the advantages of Uiua be?
Thank you! Unfortunately I'm not well positioned to do such a comparison since I don't have any APL experience. I'm hoping Connor from code_report does such a video - in the meantime he already did one for BQN vs Uiua, which might potentially cover some of the same concepts!
Yes to Glyphs! But only as an optional syntactic thing in the IDE.
I'd love to have a glyph keyboard for daily use 🙂
Your collaborators will want to murder you if you hand them glyphic code lmfao
Raku (formerly known as Perl 6) is a more traditional language that incorporates a lot of glyphs for complex operations. It's been on my list to check out for a long time now, but I've never gotten to it.
interesting I hadn't heard of this one, thanks for putting it on my radar!
@@codetothemoon Raku is basically a language that is similar to Racket where the paradigm of Language Oriented Programming and Design becomes possible since it makes it so easy to define DSLs or change Raku itself and the fact that they worked on it for almost 20 years makes it one of the most well thought out language but you have to stick to it enough to realize why it's well designed in spite of it having so many features.
Raku is multi paradigm.
You have to be a master of procedural programming, object oriented programming and functional programming standalone before even tinkling to attempt to combine them...if you try without being ready it's all going to be a huge mess.
Raku is basically Perl on steroids and you can model any language features you can think of from other programming language ecosystems.
But for production code you have to decide together with your colleagues on what features you'll never touch because it's very tempting when you have so much power in one language.
Especially the features that make it easy to write Real Only code that is succinct just for the sake of it being succinct but you loos also understand-ability of what's happening unless you're a expert in the whole Raku language and implementation itself.
I've been delving into array based languages and I really like them, I think the glyphs work in the context of these languages because a lot of the concepts are neatly founded in mathematics. On the other hand, it would be kind of messy if you used glyphs in something like rust. I know Julia and racket use glyphs in select places, for example in racket you can use the lambda character to indicate a closure or you can just write out lambda, it makes sense in this case since lambda is a long word but if every standard function had to use some kind of glyph, that could get kind of messy. Even if the linter replaced all of the words that you used with glyphs you still would have to remember enough about the glyphs to be able to read the code when you go back through it.
Being new to coding, i love the minimalistic appearance of the glyphs. It represents an intention of characters into one symbol which your visual cortex might find relief in deciphering and double checking if you typed what you intended aka looking for typos. It's a great way to avoid typos of commonly typed words/phrases/ characters. That's how i can see it being useful. Less glucose/ketones consumed by the brain means more mental stamina to code for longer. I think I might actually start using glyphs while I learn to code. Bad idea?
I think if you code using the symbolic part of the brain along with language part, you might find yourself open to being able to problem solve differently. More artistic, or creative.
This was a really good video. I would love to open up programming to more people who are dyslexic, autistic by exploring new ways to visualize the code and how you can interact with the code. I have been plagued by many issues, but I hope I can live a bit longer and create something. I think things will be changing and evolving much faster then what we thought were possible! =]
I hope The Array Cast will promote it more and more! Well done on the video, I thought only Connor Hoekstra was interested in this ; )
hah yeah I just started listening to Array Cast myself - really enjoying it so far
Scala used to allow Unicode methods and functions, but since no editor/ide allowed for easy input it become more bothersome than it was worth. You can still use Unicode in Scala, you just have to wrap the method name in back quotes. Another thing, is that some Scala users started abusing the heck out of being allowed to use symbolic names in DSLs and libraries, so they became even less widely used, because it made code bases more opaque. I think that Unicode characters should only be used in standard libraries as an alternative OR only be used in mathematical fields where it is normal to do so to begin with.
I'd love a way to translate back and forth easily from a standard language to a glyph language.
I've been looking for a wrapper file type that would contain LaTex, Markdown, Hypertext, and Document files. Open the wrapper, add metadata, pick an authoring tool and update to big screen, small screen, and print optimized. I haven't really delved into all the tools that Pandoc offers, but I haven't really seen anything that let's me write restricted HTML that updates a Markdown file and vise versa.
I can see using a glyph language similarly. Pick any programming language. Have a wrapper file that you can write in the programming language or in your glyph shorthand. Writing in one updates the other. So you have your glyphs, your language, and a documentation file linked to the wrapper. Hover over a gylph and a tooltip shows up. Hover over a piece of code and comments and documentation shows up. A more personalized IDE with a glyph option. To write in glyphs, I really think that tooltips and popup comments and documentation would help.
this is really interesting - I think you might be onto something here. so in general the idea is to get the benefits of glyphs without the downsides because you can easily just switch to writing the "traditional" way for parts of the code where doing so is preferable?
Reminds me of programming Basic on the C64 where you could/can use graphics/glyphs during programming. You can type in code a lot faster. In the Listing the syntax is shown normally. So, basically, it was more short-hand than glyph programming.
Also, if we use mainly glyphs in code aren't we changing it in a visual programming language?
Super cool idea, narrowing the gap between ai and geek (both would benefit from conciezer code against higher cost of interpretation). Also brings me back to why we communicate with smileys and abbreviations like LOL.
They need to be closely related to what they represent (make sense). And then I think glyph ratio could go a lot higher and still be very helpful.
thanks! agree that glyphs choices need to be made with great care, in stark contrast to the quick choices I made in this video 😎
Haskell is pretty rich in concepts that have mathematical history and notation, for instance forall (∀) or lambda (λ). GHC has an extension called UnicodeSyntax that enables the original glyphs for a handful of elements, and the language allows declaring aliases so you can import Data.IntSet.Unicode to do needle ∈ haystack. It's also pretty common to do similar substitutions in editor (e.g. vim conceal) and font (ligature) levels.
Matlab and Python are two pretty big languages used for heavy array processing (the latter using extensions like numpy, numba, pandas etc) that don't embrace compact glyphs. Guido specifically advocated using (x for x in xs if pred(x)) over filter(pred, xs). The Haskell form is [x | x
how do you type all this stuff? TBH I think glyphs don't make code more readable or whatever at all. maybe stack based languages use glyphs more often because their creators are more into alternative stuff/breaking with existing paradigms
If you're referring to the glyphs in Uiua, you can type a function name and it will be automatically replaced with the corresponding glyph. If you're referring to the glyphs in the Rust code, I think I copied and pasted them from Uiua pad 😎
Languages with glyphs may be interesting to explore translatable programming languages, which is to say, languages intended for usage by people who don't speak English. If your operations and maybe even function names are abstracted away from your written language, then maybe the things you actually type could be translated for your preferred language. I don't often hear discussion about the advantage English speakers have in learning programming, from most programming languages being made largely from English vocabulary and having largely English documentation. Having English as a native language myself though, I don't have much knowledge in this area.
This all said, I don't think heavy usage of glyphs is very practical, because at the end of the day, if they're not on someone's keyboard, they would have to type and understand it as whatever word it gets mapped to, *unless* macros are used, but I think those are also impractical.
I fully agree, the use of glyphs in an imperative and functional languages would be a game changer.
potentially!
This is a great language, it has cool ideas. I am a Java developer and the python syntax really got me using the language. It was clean and easy to read. I myself don't like a lot of words on the screen. I am a graphical thinker, and looking at this made me think how easy it would be to read code using glyphs. They are clean and short you can definitely express complex code using them. They would still be readable. Uiua is breath of fresh air
Glyphs are hard to type in.
I have been thinking about a similar problem using operators. My goal is to have each character mean only one thing. By combining characters you can create more complex operations. This gives the dev a fighting chance to learn only a few dozen characters and be able to decipher a large set of operators. The hard part is designing the operator character language in such a way that it stays logical and consistent.
I've used BQN (an inspiration for Uiua) a lot.
Typing the glyphs is something that takes about a week or two to adapt to. I use a keyboard layout where I hold down right alt to input these glyphs but people also use editor plugins that will input a glyph when you backlash then type something. What Uiua uses is typing out key words that get converted at run time.
I feel hamstrung in other langs because of how many lines it takes for me to express something like this ∾⍟(0⌈1-˜≡) (its a crude way of completely flattening a N-deep list). Glyphs make a big difference.
To your question regarding math/glyph ratio, i think academics are more used and equipped to interchange glyphs and other symbols for words and vice versa. So it makes more sense to academics then to others. Doesn’t make it a bad idea per se.
I think you would need an ide that can swap between the two. That would greatly improve adoption.
yeah definitely true. I agree with the IDE visual swap approach - I think that's probably the only way to get any sort of mainstream adoption
One idea could be to use glyphs to represent those native language features where you could presume better compiler optimizations or interpreter optimal functions.
In other words, that the use of the glyph represents some thing that is different from naming a dynamic function or something like that.
Dyalog APL is as fast as C++ in quite a lot of operations.
Haskell, for example, allows defining infix operators (such as >>=, , , $, >=>, >>>, etc.), and it works just fine. In fact, those are just regular functions, hover over them, and the type signature is right there. Turning those operators info glyphs is matter of using a font that supports ligatures.
Wouldn't writing a glyph be a pain without a key for it on your keyboard? You could have them auto replace based on text, but at that point you maybe a font with ligatures would work just as well?
I like the idea, but it has to be done right. In order for it to work the glyphs would need to be easily recognizable and representative of their function (even for beginners) and they need to be accessible for typing. Also there needs to be official aliases using ordinary descriptive names (map, sqrt, etc.) so you can choose what makes sense for you. I've been looking into Julia, and it has an integer division operation using 'a÷b', which has an alias function 'div(a,b)'.
totally agree with everything you said. I think what you mention is the only way to truly make them accessible from an input perspective - every glyph function would have an equivalent descriptive name that could be used instead to invoke that function, and that can potentially be converted to a glyph at some point
Glyphs are good and somewhat type-able nowadays. I think the main issue is that it's only a mildly useful thing to have for multi-paradigm, broadly procedural (including OOP) general purpose programming languages. For those who don't know, that's almost everything used in industry. Also, even though it shouldn't be hard I feel like a large percentage of language projects would somehow really mess up their compilers if they implemented glyphs.
glyphs are great and when we use them they are awsome. I think what this video really bbrings to mind is how many things probably should be glyphs that arent rather then the idea that we should completely rewrite programming langauges using glyphs. The issue is that glyphs generally are harder to intuit then words and simultaniously are far more compact then words, which means the complexity per visible unit can be waaaay higher, this is awesome when you become familiar with a concept, IE lambdas, negation, addition(which all currently have glphs that work great). The problem is in custom defined glyphs which I dont think is really being suggested, the issue there is that any individuals code is rarely going to be interacted frequently enough to test if the glyph is intuitive for the usecase, and if its not theres rarely enough usage to justify learning it. They can also be harder to type and typing out the word often times removes the utility of the shorter glyph syntax to some degree.
Conclusions/thoughts:
1) Glyphs (probably as alternative standard) are great and should be used for more common functions in standard libraries. ! is way easier then pythons not
2) Glyphs are already used to some extent
3) people need to be familiar with glyphs for them to be good
4) we should come up with a standard common and logical set of glyphs
5) we should improve the typing experience for some glyphs via macros and keyboard layers
6) we should be careful to limit the number of glyphs to primatives that currently lack them like maps, filters, ranges
7) Readability of glyphs is important. Glyphs should be large. some of these symbols are smaller then normal text which is not ideal in some scenarios and making sure they are easily visually differentiable is vital to preventing annoying to debug errors. this is extra true if functionality is similar to be fair one solution to this is coloring commonly confused glyphs differently.
8) we can compose common visual notation with glyphs to effortlessly convey extra information for example a slash through common glyphs to convey the inverse or negation ie filter could be whitelist slash filter can be blacklist
9) Personally defined glyphs in editors would be great, this is kind of what ligatures are I think it wouldent be too hard to write a really easy syntax that automatically inlines glyphs into common editors without any actual glyphs being passed to the language this means the user can highly customize for their own usecase without disrupting readability.
10) Glyphs should be more important the longer/less compressable the phrase is, there are some programming primatives which just dont have great shortand representations, function declaration and let have reasonably been shortend to "fn" and "let" respectively so the benefit barely exists here aside from in visual space. There is massive benefit however to making a primative print and print LN glyph ideally with roughly simmilar symbols. I dont know of good shorthand for printing or logging statements yet these are really common primatives
11) Glyphs need not be limited to keywords they can also be word segments, for example if we developed a common gliph for line, then something like print line could be print glyph plus line glyph the standard output and error could also have their own glpyhs.
12) a secret benefit of glyphs is that they can reduce language specific terminology, although in the short hand they will definitely increase it. Glyphs are less likely to be reinterpreted as weve seen with things like the not ! operator and the or | operator if we really rigidly wrote a standard since glyphs are basically not in use today that standard has a good chance of becoming pretty universal.
I think an important question here is just what kind of keyboard do you use for all of this. How do you create a layout with all of the relevant glyphs and make it easy to learn. One of the beauties of programming is that it can be typed out, and over time various programs have made the process faster with QOL additives, but glyphs take this a step further where you're now completing entire lines of code with a few simple glyphs. I really want someone to tackle the physical side of this, and not just a 'I made a random layout and learned it myself' as not everyone will learn that same layout like we have with the standard language-numeral cluster. If someone can find a layout that makes sense and is easy to learn, and if all of these languages adopt the same glyphset for the same relevant functions, then I could see wider adoption; but the problem with that is the glyphset, changes between languages can easily be adapted to via typing words and common symbols, yet a change in glyph can wreck the learning process of a programming language, and worse it can wreck a keyboard layout, and I doubt anyone is going to want to rebind and relegend (even with just swapping keycaps) a keyboard just to go from language A to language B. There's also an issue of glyph scope, ever seen a Kanji keyboard (the old ones with something like 500 keys in an ortholinear arrangement), no programmer is going to want to deal with that many glyphs, not to mention touch typing will be damn near impossible with a glyph set of that size. There just needs to be simplicity and consistency across the glyph-based industry with a keyboard that also reflects these values; a change of language should be a simple change, a change of peripheral should be a simple change, you should not have to relearn glyphs nor relearn how to type, this is the only way glyph-based languages and their adoption makes sense.
A software solution might be better for this imo. Where you write code normally and when you turn it on, it gets replaced with those glyphs.
If you're on line 7, it will show normal keywords but rest of the code will be filled with glyphs.
I agree that this approach makes sense and make it more likely to be adopted by the mainstream
My impression from ~18 months of lurking around array langs but writing very little code is that they are much better suited than "normal" languages for using glyphs because a core premise of array-based programming is that you have a small number of basic functions (primitives) with very well-defined behavior and you build all the more complex functions from them. That everything in these languages is an array makes this possible. The glyphs/primitives act on arrays, so their compositions/combinations will also act on arrays.
Of course you can make use of glyphs in non-array languages, but the fact that the most basic operations in the language are represented by glyphs is what makes this convention feel natural/elegant/easy-to-keep-in-mind in an array language.
Interesting and enlightening.
This feels alphabetic to pictorial to me, opposite of human languages from a timeline perspective. Yes, it's fine to have the density. But how do I input the symbols? Pinyin convention for Uiua? Sound it out? We developed the alphabet (not invented) in Latin scripts as an abstraction on mouth sounds. Korean developed (invented) an alphabet inspired by mouth shape but still an abstraction on the concept. If we pick a mappy looking glyph for map() then we are doing pictures like Bone Script before Mandarin. Map doesn't have a picture but filter does if we used Excel's icon.
I’ve heard Swift lets you use emojis as variables. Wouldn’t that make it a really good test bench for this idea. I’m not a Swift programmer so I’m not sure if functions can be emojis too.
We have a lot of glyphs in ligature fonts as it is. When I code with FiraCode or a similar font, => and other such symbols get drawn as arrows.
i think glyphs are in general less readable, but extremely beautiful. it's awesome to see a whole line of text reduce to just 5 to 7 glyphs, and it makes me wish i had that instinctive intuition for what the glyphs meant
I don't think anyone can rely on instinctive intuition when it comes to the glyphs - it's just a matter of repetition and investing time into learning them. I picked the glyphs for the Rust example on a whim, and when I look at that file now I have no clue what the glyphs I chose mean without looking back at the original
@@codetothemoonExactly this. It's so hard to remember all of them and you lose familiarity really quick. You would have to work with it constantly.
At that point it's like, what are we even gaining other than being able to jerk off about our terse-ness. It actually seems pretty useful if you just use the English syntax instead of the glyphs. At that point though, why not just use something like Lisp or Haskell.
There's a Rust twitch streamer - I forget who - that uses glyph ligatures (like the '>=' conversion to ≥ that Fira Code does) for many of the Rust keywords.
whoa interesting! I suspected I might not be the only one with this idea... would love to figure out who!
8:38 that looks like the prettiest code i've seen
No Glyphs is COBOL. But having the ability to use a slider with different levels would be a good way in, especially if the compiler can choose to not use glyphs in its errors. It would be a fun macro.
I'm deep into BQN and I think glyphs are amazing. I think when you design a language with glyphs, you need to be way more careful about what what algorithms you want a full glyph for in your language since the programmer needs to recognise and get comfortable with each one of them. I think that's why the APL/array languages generally consist of an amazing set of essential algorithms. And on top of that we have an amazing hyper-general set of ways to combine and compose these algorithms together. That makes it so you don't often abstract away logic behind function names. You read these algorithms and often-used compositions of these algorithms very quickly. So you end up being way closer to the actual algorithms which makes it easier to spot patterns / iterate. Single characters can hold a ton of knowledge, power and beauty in certain contexts. Ooh yea and I think array languages work well for glyphs and imperative languages less so since array language are like hyper generalised since everything is an array which makes almost every function and system fit together natively. If you have tons of different types, things are very hard to generalise and you'd need a ton of glyphs for every combination or type of thing.
A glyphy Javascript would be interesting! Compiled Javascript is almost glyphs with their minified function names. Minified compiled JS is pretty compact, but it may become more so when the other statements are also glyphs, like if-elses, function declares, and switches.
Glyphs when done correctly really help with reability. Just trying to apply to rust does not capture this.
Remember that APL was first a math notation before a programming language.
What is the gap between how we might apply them to Rust and the optimal way to use them?
@@codetothemoon It's not that they couldn't be applied, but that they would probably work better as a DSL within rust.
Main reasons for this:
1. Array languages have very specific rules around order of execution. This enables automatic variable passing and clear execution. This order often does not match what you would see in a language like rust. As a simple example in bqn the average of n is (+´÷≠)n. Read as sum divide by count of n. In a language like rust, even with symbols, you would need to write some like +´n÷≠n. This duplication of n is not much of a problem here, but can get really bad in larger expressions. It also means more values need names and can't just be piped around the code.
2. Array languages to to run right to left. This is important for readability while chaining symbols.
3. Rust simply has many functions that do not map to array language concepts and naming conventions. You would probably need way more symbols and complexity to simply map all of the functions an iterator in rust can support.
4. Rust is not dynamically typed. Array languages tend to play with type quite a bit.
I do think that some for of array or iterator in rust that works with a dsl that is an array lanaguage could work really well. Given uiua is written in Rust, it may actually be able to full that gap.
makes the code so much more readable even if not comprehendable at first. id be in favor of increasing the number of glyphs
nice, I agree but it sounds like we might be in the minority here haha
Language that balances glyphs and letters: Japanese. 漢字で書けます - the first two symbols are glyphs that combine to mean "glyph" the third is a letter (meaning "in"). The fourth is a glyph for written text and the rest are letters that combine with the glyph to make it "I write."
I think the glyphs actually being ligatures would be nice and kind of neat.
Agree 💯
IMHO glyphs make more sense in array languages, where you get things done by stringing together a relatively small number of highly composable operations. In most languages there are two many operations -- if you had to learn a glyph for each, it would be too much. And they don't fit together as cleanly.
I have wished at times that I could replace functional code like foos.iter().map(f).collect() with something more succinct, but it probably wouldn't fit well with the language.
I do appreciate that the Rust folks chose to shorten a lot of common identifiers, e.g. fn for function, u8 for unsigned char, pub for public, etc.
One thing I think would potentially be useful is to have a set of glyphs to read code, but have them "unwrap" while typing the code. This would me similar to an IME for Japanese, where you type にほんご but it transforms to 日本語. When you go to edit the text, it can "unwrap" into roman characters to be more easy to type, and remember if you don't know the symbols, but once trained, you could easily read more complex code shown in glyphs without "cheating" and checking them. This solves the inability to easily type things, and much of the transition period. It can also be stored in basic ASCII text and rendered in glyph or not based on what the editor was set to. Everyone wins.
That's literally how the web Uiua editor works. You can type stuff like "reverse" or just "rev" and when you actually run the code it changes into ⇌
I like the idea but i generally go against main stream programming :). haskell lens library a good example, beyond the basic handful of symbols, can get very hard to read but if you keep doing it for long enough it isn't any less readable than words.
Raku is a general purpose language that makes great use of glyphs.
ahh I didn't realize this! Raku has been on my list of stuff to check out for awhile, hoping to get to it at some point...
I like the readability, but the barrier to entry becomes much larger. Not to mention how would they work with intellisence or keyboards in general.
I could almost see emojis being a good replacement, especially since most oses have emoji keyboards.
I think glyphs would be great if they could be use in one line.
So a complicated algorithm would become a short one liner
This is a form of compression
Like a highly compressed scripting language.
The backend interpreter/compiler would still be large but the short online scripts would be extremely powerful
glyph's belong where the things you are replacing are so well defined common and ubiquitous that, like common operations on whole categories. Takes a fair bit of maturity of the field to go from phonetic to glyph.
Glyphs are very interesting. Indeed they have the potential to convey a more concise and readable code. However it's important to choose those whose meaning would be obvious. As an example, we could use the emoji of a map 🗺️ as a metaphor of the map function. I personally like to use speech balloon glyphs to represent the beginning of a line comment: 💬 Line comment. Or the little finger for promises 🤙. Also there are lots of unicode symbols that could be used as well.
Re glyphs and other undecipherable symbols: check out Agda and lens operators in Haskell
Re Uiua: does it actually execute from right to left?
I kind of like the glyphs in the filter, map etc part of rust, those lines tend to be kind of long so having glyphs to shorten them can make them more readable. I don't like the infinity symbol for function (or arrow for let) they feel kind of wasted and unintuitive. Having an arrow for vec makes sense to me though it still feels kind of wasted
I use APL quite often. This is in the uncanny valley from that. Just different enough to make me angry at times 😅
oh nice do you use it professionally? What do you find it is better fit for than mainstream languages? What do you mean by uncanny valley?
@@codetothemoon Not professionally (sadly), just as a hobby, I'm a C++ dev professionally. I find it kind of different in an interesting way. It's better for the stuff I'd do with SIMD instructions anyway. I made quite a few genetic, memetic algorithms using multi dimensional arrays only (for production scheduling). It has pretty good performance. The uncanny valley being the small differences that are hard to memorize: e.g. a similar symbol that does something else.
Common math operators are glyphs. Plus is a glyph. Of course it's a good idea to use them for common operators. But to not go too far. Sqrt has a glyph too but we don't use that. The optimal is when it's up to the user and they can be switched to text and then integrated as a symbol when the programmer is familiar with them.
In code fonts they have ligature which would display != as ≠, maybe reverse ligature could display the symbols as text
It's a fun idea / academic experiment, but I feel like using just roughly 26 characters to form words in English is way easier to learn than thousands of glyphs in Chinese (for example). Judicious use of syntactic sugar to shorten code (such as the question mark operator) is welcome though.
I think you're missing the whole aspect of tacit programming and combinator use in array languages since you're not as familiar with them. The real selling feature for array languages for me is being able to write(and mostly read) really terse and complex functions. Do I prefer the glyph version of the rust code over the original? Not really. I don't think the glyphs really add anything in terms of reading or writing code. But being able to write that function in one line and a tenth of the characters in APL or Uiua is a killer feature. I really like using APL on my phone for small but relatively complex calculations for example. Uiua should be great on phones with the glyph parsing and I hope they do a dedicated mobile interface/app. Anyway, combinators are really what enable this and I think more languages should have them as a first class feature.
One issue with glyphs is keyboards don't got the symbols on the keys, so either you would be spelling out the names of the functions/operators/whatever as you would without glyphs, or you would have to memorize a bunch of unmarked keyboard shortcuts. Might make for a more compact display of the code, but that would be sacrificing readability for people that have not memorized all the glyphs; essentially making it a form of obfuscation significant benefits for the people writing the code.
Though, maybe it could make sense, considering how in more advanced math, people do learn a ton of extra symbols, and we do see those symbols being used in scientific papers, textbooks, certain scientific publications online etc.
In uiua you type in the name of the glyph, and the name is given every time you click a glyph
@@sycration I did mention that approach in my comment
Consider using emoji or logograms (Chinese characters) instead of just glyphs. And it is possible to properly input logograms from any keyboard (I guess, I saw it in anime 🤔)
I always hated no operator overloading people and this gives me so much joy.
In a way, mathematical notation are a set of glyphs. I think a lot of glyph languages, like APL, have glyphs that look so foreign to me. So I dont have an easy time associating the glyph to anything I already know. This is my main problem with a lot of glyph languages - I wish they could more easily connect to glyphs already seen in math and science. Or were more common. Maybe they are, and I am just missing the education to catch the association. Anyways, thanks for the content!
It would be like the Chinese language. They basically have glyphs for words. It would be an interesting idea to train oneself to insert certain worlds using shortcuts or have certain chars you can type on a Mac using the option key into things like "def" or "fn" or "into_iter". etc
exactly!
unsure if the transpose symbol is a dogwhistle or a off key sign of support...
lol yeah - I suspect there will be extensive debates over whether a given glyph is a good fit for what it represents, and what it *actually* looks like...
The use of glyphs would be a good reason to get a custom keyboard - autocomplete (i.e., from "range" to its glyph) is nice, but a custom keyboard with all of those would be kinda cool. Not practical, but cool 😅
Think that Uiua will be advent of code ready?
I would expect some kind of glyph operators for NumPy arrays
seems plausible, off of the top of my head not sure if Python supports any unicode characters in function names though
How do you code, type all of this? Or are they only the "pretty" representation of your code?
if you're referring to Uiua, you can type function names and they will automatically be replaced with glyphs when you press "run". If you're referring to the glyphs in the Rust code, I think I copied and pasted them from Uiua pad 🙃
Personally I think glyphs suck, as others have noted the further you go from the standard keyboard the harder it is to type, and they're harder to understand if you're only using the language occasionally, however in math operations and formatting operations (think latex) they make intuitive sense to include as an option.
The video "BQN vs Uiua" was my first introduction to these array languages, I didn't really know what to think. I can kinda see the power in them, but at the same time I'm not sure if they make solving the problem at hand easier, or more challenging. At the first glance looks more akin to puzzle solving than programming. What do you think?
fair question - I've been down the same line of questioning. I wound up deciding that they are likely preferable for very specific domains - the one that immediately comes to mind is image generation / manipulation, statistics, and possibly machine learning and computer vision. I'm trying to learn more about how they are being used in the industry so I can get a better sense of where they more "proven" to be a good fit
"...more akin to puzzle solving than programming."
What's the difference?
I'm mainly using Uiua for Advent of Code challenges right now because it's fun and interesting, but it becomes easier and easier every day, just like regular programming, and I don't know, maybe some day I'll use it for a personal project. Someone on the community discord already implemented a simple raytracer in uiua in ~120 lines, including comments.
So I guess like with every language, it's difficult initially when you don't know all the function names, but if you're proficient enough, some problems are easier to solve than in some other languages.
I imagine myself (or, rather, someone much smarter) going down this rabbit hole, mastering it, and one day opening Uiua pad during a tech interview to solve their Leetcode hard question using a single line of esoteric runes. 🤭
Looks like some ancient or an alien language. I personally don't understand why there are glyphs instead regular names? Is it so it's independent from human language such as English maybe?
Edit: For the Rust example, maybe if someone likes glyphs more, an editor and LSP understanding the language could replace and change the function names with glyphs and back when loading and saving the file. So the saved file is always a regular file, but looking it with the special editor (or an addon), it would show the glyphs instead. So one could work with glyphs and still push and work on standard files with others on the same project. Just an idea.
One big reason APL uses compact symbols had to do with Iverson's thoughts around having a small, concrete language. If this is a convention in newer array programming languages it may be so because of the influence of APL, which in turn would have been influenced by working mathematicians and scientists. There is probably a strong correlation between short symbols and tacit programming styles in general.
I remember the first time I've seen a javascript code when I have ZERO clue about computers/programming languages, Its like I'm looking at some noodles with english alphabet forming somewhere inside its madness.
I see the same thing with this, its like looking at an alien language at first, but if you get the hang of it, I think this could be much easier to build a logic and structure a code with less characters
if you'd show me the glyphs structure you created vs its rust equivalent 15-20 years ago (when I have zero clue how computer works), and asked me which I think would be easier/I'm willing to LEARN, I would probably lean towards glyphs.
totally agree - it's really hard to consider the glyphs approach objectively when we're all so intimately familiar with existing languages. Maybe the best litmus test would be running these things by somebody who has no coding experience at all!
Side Note: using vec!() instead of vec![] feels like a war crime
lol - I'm still not entirely sure why vec! supports different delimiters that each provide the same functionality
@@codetothemoon It's every macro. you can write println![] if you wanted to
I don't think the tradeoffs are the same. I'd say that languages that process data through a pipeline that is uniform are more likely to use glyphs or more broadly single character keywords. Regex would be an example where glyphs could have been used but instead it uses single character keywords from the standard alphabet. Data processing languages don't need as much extensibility because they are pure and operate on one data type. While imperative languages that deal with more logic, types, and state management need programmers to define more of their own tools, which will have names, which will be tokens, so it's expected the programmer is going to be using tokens any way.
So then there is the in between, functional languages. They use both. Haskell has a ton of operators and users have defined modules with even more operators, but also has named core features like map. Elixr also has examples.
What you call stack notatxon, i believe, is called Polish notation in math.
ahh yes thanks for pointing this out!
It reminds me of symbols used in mathematics. Compared to characters, glyphs are not very flexible, so to me they don't seem like a good choice for anything other language keywords.
Font matters a lot for language that relies on glyphs, so having fonts specifically designed/adjusted for them can help a lot.
There's an extension for vscode that automatically replaces your defined keywords to glyphs in the view, while keeping characters unchanged in code. You can use it to experiment adding glyphs to Rust.
Do you know the name of the extension that does this? I would love to try it out and I cannot find it after spending the last 20 minutes searching.
@@Phscyoman I don't remember its name, and on my phone I couldn't find it either, it's hard to find search keywords for it! IIRC, it wasn't specifically for glyphs, it could swap predefined strings of characters to something else, for example, instead of fn, you would see λ. Kinda like how glyphs turn into a new visual form, but underneath they're just ASCII characters, but extended to work with whatever you define.
I remember it as well, I don't know the name either. It was meant to be an alternative for code ligature fonts. I found it to be really slow though, so I stopped using it. Using fonts supporting code ligatures and enabling them in vscode was much faster. It isn't as extensible though since you only have what the font provides
@@mhmdkzr Darn maybe Ill just have to make a font with ligatures that are based on the keywords in the languages I use.
@@Phscyoman That would be amazing! I would love to try that. It would also be the fastest and most compatible way.
Maybe you could write a program that would make the necessary modifications to the given font, based on the given keywords and glyphs.
man, reading someone else's spaghetti code is hard enough. cant even imagine reading someone else's spaghetti WHILE decyphering hieroglyphics
I don't care about concise code, i care about readable and debuggable code
Why ⁉️ use 💡 something Singular 🎯 and Universal 🌎, let's 💡 randomly 🎲 generate 🧬 our 👐 own 👐 programming 💻 languages 🗣️ for 🤲 each 🧮 project 🔨 and use 💡 all 👐 of utf-16 🎉 for 🤲 this 🤲, I 👥 like 👍 this 🤲 idea 👍 so 🆘 much ❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤ can't 🚫 wait ⏳ to see 👀 that 🤲 in 🤲 reality 🥰😍
Let’s do it! 🚀
We ousted "goto", we introduced indentation, we got code colors and we overcame the 8.3 character DOS convention and called out things like "x=blub*bla" as horrible constructs.
All to ease the understanding of the written language (what code is). All of that for readability and that you can come back after a month and still comprehend what you fabricated there:) NOW ... why not go back to the days of Assembly Language ... or better: EFFING Machine Code?! What a stoopid, childish and at all: a backwards idea!
But who am I. You do you! Thanks for the video and your thoughts.
P.S.: Yeah, it's short. And maybe even some kind of pretty with the help of special visibility tools. People who are fluent in things like vi-shortcuts and Egypt Hieroglyphs maybe love that glyphs idea. It's short and saves memory and for some even time(but for the majority it will cost brain cells and anger!)?! But by argumentation like exactly this way you can even "justify" genocide. I'm not convinced:)
Honestly, I agree, It does seem difficult to learn! 😅
But I feel like a language or two wouldn't hurt a bit, Might even be cool!
But I think I'd prefer the text based setup we already got either way, But that's just personally! 🙃
if by "a language or two" you mean "a glyph or two", i'd agree! and i also agree with entry remaining text, with the glyphs only being for display
@@codetothemoon I actually meant a standard language or two that supports glyphs, I probably wouldn't study them, But they'd be cool! 🙃
I wish I was living in the timeline where apl and array languages became the dominant paradigm