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 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.

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

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.

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!

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.

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

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.

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 😅).

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

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.

The global stack concept is pretty intuitive if you have ever used an old school calculator with RPN (reverse polish notation)

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).

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).

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 ; )

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.

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.

I use APL quite often. This is in the uncanny valley from that. Just different enough to make me angry at times 😅

Yes to Glyphs! But only as an optional syntactic thing in the IDE. I'd love to have a glyph keyboard for daily use 🙂

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

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.

Interesting video! What I really missed was a comparison with APL (that you mentioned). What, if any, would the advantages of Uiua be?

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.

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.

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.

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.

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.

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

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.

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.

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.

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 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

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.

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.

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.

What you call stack notatxon, i believe, is called Polish notation in math.

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.

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

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 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.

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

Side Note: using vec!() instead of vec![] feels like a war crime

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.

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 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.

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.

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

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

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?

8:38 that looks like the prettiest code i've seen

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.

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.

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.

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.

makes the code so much more readable even if not comprehendable at first. id be in favor of increasing the number of glyphs

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 🥰😍

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.

glyphs are just what the language parses. they allow people of non english native languages to have identical nativeness. floor is english but _ is universal.

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.

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)'.

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?

so basically a programming language is a translation of math statements into binary code that is readable by computer into english-like code that is readable by human, and uiua is translating it back to math statements. sick

Raku is a general purpose language that makes great use of glyphs.

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.

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.

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.

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.

I think the glyphs actually being ligatures would be nice and kind of neat.

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 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.

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:)

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.

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.

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.

I always hated no operator overloading people and this gives me so much joy.

Nobody knows how to type these glyphs on a standard keyboard. I certainly don’t.

Love it as a intellectual challenge, but In my opinion the reason for Python and JavaScript are popular is because for a someone that is making their first steps on programing is that you can read the code and understand at least 40% of the code. Because you have words that explains the functions. Like PRINT - is telling you what is doing. Imagine the same person trying to make a simple program and need to learn and remember symbols. The problem is that it will be make the process of learning the first steps on programing more difficult. So it will be less popular and only for experts that are boring. No suitable for large projects unless you learn the glyphs and their meaning together with you A-Z.

While this is cool, I see this as a minimal benefit over the struggles of getting to grips with this. In most functional languages, everything is written in English. This means that anyone who speaks English (which fortunately seems to be most of the world, at least at second language basis) can get an intuitive understanding of the purpose and usage of a function based on its name. Using these glyphs would reduce the size of code, and tbh do look very cool, but beyond that it would severely increase the learning curve for programming and negatively impact the readability of the code. I could see glyphs being used in extremely repetitive situations with complex names (Thinking about quantum languages where low level languages would need to access a lot of quantum functions that could have very long names) but at the same time, that's what abbreviation is for (In Rust, iter vs iterator). While an option to replace functions with glyphs would be useful, I don't want to be the poor programmer being introduced to these glyphs for the first time upon joining a mature development team...

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.

Realistically, we already use a lot of glyphs in our code. Code being nothing more than a human interface for machine code in the end. The only reason why an up-arrow is less legible to a programmer than the sequence of letters: "range" is because people who have taken the time to be able to read english, already know what that sequence means. If you want to add glyphs to a language and find a happy medium between when to use written language vs single glyphs or iconography, then split your code into data and logic. Data could simply remain to be language as it is effectively the variable aspect of information that is passed to your logic. Effectively labelling or representing what the variables should contain. Whereas the logic is the bit that should remain unchanged. (Unless you want your code to do randomly different things I guess?) A similar thing is currently the case in other universal language, like Maths. Where most operations and logic is portrayed using symbols that tend to differ from natural language, whereas the variables are almost always shown as letters. +, *, /, %, etc. are all operations or flow control, functionality. a, b, c, look like variables in any formula to anybody who has passed at least high-school maths class. What reads easier to you? y = a * x ^ 2 + b * x + c or let y = add(add(multiply(a, square(x)), multiply(b, x)), c); or perhaps it is easier for people who do not know maths if I write out all the steps more elaborately?

ive knocked out basically all the keywords in python with symbols and honestly I love it so much more, less code = more readable for me for some reason lol

Re glyphs and other undecipherable symbols: check out Agda and lens operators in Haskell Re Uiua: does it actually execute from right to left?

How do you code, type all of this? Or are they only the "pretty" representation of your code?

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!

In code fonts they have ligature which would display != as ≠, maybe reverse ligature could display the symbols as text

There is definitely a balance between the "proper" amount of glyphs. But Uiua looks like a meme language. I could maybe see a glyph for match, collect or to_string.

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 🤔)

Having glyphs makes it hard to think and talk about the Code. Like you can ask your colleague: "Oh, what does the filter function do?" Instead of "Oh there is an oparator shaped like a vertical line with a dash...", "Is the dash pointing left or right"? "To the right..." "And the line is completely vertical, or a bit sloped?"...

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.

the threshold is 1 (archaic) glyph (i say archaic since technically ever character we type is a glyph). no thanks. there are 2 deal breakers in this design choice: if i can't type it on my keyboard it's a deal breaker. if i have to memorize archaic symbols, it's a deal breaker. it's a bad idea even in the uiua language, since the glyphs give out hints if you hover over them. it makes it somewhat tolerable in their editor since all the glyphs are in a toolbar.

Most array-based languages use glyphs because they take direct inspiration from APL

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

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.

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 wish I was living in the timeline where apl and array languages became the dominant paradigm

Remember those kinds of languages were supposed to be used by mathematicians, who might not have known English, but will absolutely learn some new notation provided there is a definition of what the symbol means ;)

yeah but it's easy to forget that every glyph-based language needs a corresponding editor, needs to be on a system that can render utf8, and even IDEs like vscode will still need plugins for things such as a glyph toolbar, intellisense, or some sort of text-to-glyph conversion shortcut. I think the better course of action is to just write code that is nicely formatted with auto-formatters. I don't really see the benefit of bringing glyphs into Rust. The only reason glyphs are useful in array languages is because of their point-free design. I.e. glyphs are useful in the context of combinators. But if they aren't providing a semantic or design shortcut, then they are not worth a syntactical or spelling shortcut. Finally, imo, glyphs aren't generally needed since it is better to use short function and variable names, and provide context to their meaning through encapsulation in modules/namespaces or classes/structs or plain-objects (typescript).