Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uiua: A minimal stack-based, array-based language

uiua.org

Post reply on HN
Print view View original

81–90 of 107 posts

Re: Uiua: A minimal stack-based, array-based language

#81

Post by bmacho »

kaikalii wrote: post #33

Oh hey, I made this. Cool to see it at the top of HN!

I hate right to left. In my mind functions act from the right. They are even denoted with a little arrow pointing left to right. Thank god OOP methods, UFCS and streams/pipes and nearly everything goes from left to right, top to down. (AFAIK not long ago some algebraists tried to do algebra, linear algebra and category theory left to right, so f:A->B and g:B->C would compose to fg/fog/f.g.. :A->C. But probably they do it less nowadays, the attempt failed, and math remains right to left.)

Why is Uiua right to left?

Re: Uiua: A minimal stack-based, array-based language

#84

Post by gpm »

ramon156 wrote: post #82

So my biggest question is, what can I use this for? I get most languages start as fun hobby projects, but there must be some thought behind this concept right?

Some people really like the idea of concatenative languages. I think this is probably reasonably viewed as "research into making those actually usable", in addition to a fun hobby project.

Here's a blog post that tries to motivate them: https://evincarofautumn.blogspot.com/2012/02/why-concatenati...

Here's another interesting recent attempt: https://www.dawn-lang.org/posts/introducing-dawn-(part-1)/

Re: Uiua: A minimal stack-based, array-based language

#85

Post by saulpw »

robertlagrant wrote: post #67
saulpw wrote: post #26

Earlier quoted context omitted.

APL people often point to the definition of "average" as evidence for its economy of expression: +/÷≢ They make the argument "the word 'average' has more symbols than its definition, so why not just use the definition inline as a tacit function?" There's some elegant beauty in this that I'm sympathetic to. However, I think it's fundamentally flawed for one big reason, which in my opinion is the core of the unreadabil…

> Humans think in words, not letters In some languages, e.g. Chinese, each symbol means more than a single letter would in a latin alphabet. These languages to me are just a bit more like that.

Each kanji in Chinese is a full word. The "letters" are the radicals, which do not contribute to the meaning.

Re: Uiua: A minimal stack-based, array-based language

#86

Post by spicybright »

bobterryo wrote: post #59
spicybright wrote: post #17

Earlier quoted context omitted.

Could you recommend a good starting episode? I know the generals of languages so I don't know if episode 1 is worth the time investment...

My favorite episodes were Stevan Apter, Leslie Goldsmith, Lib Gibson, Rob Pike and Jeremy Howard. If you want to go deep into the concepts focus on the tacit episodes or the ones with John Earnest or Aaron Hsu. There are transcripts with each episode so you can always read if your time is that valuable. https://www.arraycast.com/episodes Full disclosure: I am on the ArrayCast

Thank you!! I have a long drive ahead of me today so this is very welcome.

Re: Uiua: A minimal stack-based, array-based language

#87

Post by bmacho »

bmacho wrote: post #81
kaikalii wrote: post #33

Oh hey, I made this. Cool to see it at the top of HN!

I hate right to left. In my mind functions act from the right. They are even denoted with a little arrow pointing left to right. Thank god OOP methods, UFCS and streams/pipes and nearly everything goes from left to right, top to down. (AFAIK not long ago some algebraists tried to do algebra, linear algebra and category theory left to right, so f:A->B and g:B->C would compose to fg/fog/f.g.. :A->C. But probably they d…

Probably this way you can have sequential and anti-sequential parts without parentheses?

Re: Uiua: A minimal stack-based, array-based language

#88

Post by robertlagrant »

saulpw wrote: post #85
robertlagrant wrote: post #67

Earlier quoted context omitted.

> Humans think in words, not letters In some languages, e.g. Chinese, each symbol means more than a single letter would in a latin alphabet. These languages to me are just a bit more like that.

Each kanji in Chinese is a full word. The "letters" are the radicals, which do not contribute to the meaning.

Sure, but...that's my point. In APL those characters aren't letters either, they're words.

I agree with your overall point (which is, I think, DRY) but not this specific criticism.

Re: Uiua: A minimal stack-based, array-based language

#89

Post by ithkuil »

derefr wrote: post #79
ithkuil wrote: post #55

Earlier quoted context omitted.

Like k

Visually would look kind of like K, yes; but K (obviously) isn't a stack language, and more importantly, K has operators that consist of multiple characters, and circumfix operators like {}, etc. So it really has none of the qualities that a bytecode has. Whereas Uiua/ASCII would have all of the qualities that a bytecode has.

Does Uiua still have to do some parsing for parenthesis for functions?

Re: Uiua: A minimal stack-based, array-based language

#90

Post by diogenes4 »

082349872349872 wrote: post #9
diogenes4 wrote: post #8

I'm a big fan of stack-based languages conceptually, but they always seem to fall flat when it comes to basic reading comprehension. APL has the same issue, as does J. Factor did improve on this a little bit by eschewing the symbol fetish but it was still very difficult to rapidly scan the code for functionality. I'm not convinced the approach shown here is a good pairing with the human brain.

If (and I grant, this is a big if ) you are used to them, the symbolic nature of APLs allows to discuss code fragments (and even entire* algorithms) using inline elements instead of as separate interspersed blocks. The difference between scanning algol-style and apl-style code is a little like the difference between scanning history books and maths books: on one hand, one must scan the latter much more slowly (symbol…

> If (and I grant, this is a big if) you are used to them, the symbolic nature of APLs allows to discuss code fragments (and even entire* algorithms) using inline elements instead of as separate interspersed blocks.

So I easily grant you this, though I don't think it's much different in practice than using subroutines.

But even if I grant you that a high level of experience allows rapid scanning, there's still a barrier of translating to and from English (or whatever language you develop in) that seems to be higher due to the symbolic nature of the language. This is also true with certain procedural languages, but there's also been an enormous number of think pieces about how best to encode procedural programs so that they do naturally translate into natural language domains. I'd imagine that not being able to leverage those decades of discussion straightforwardly would be a loss.

Granted, this is also a problem with stuff like Haskell too, but the type system goes a long way to ameliorating this concern by classifying structures very rigidly.

Post reply on HN