The OK? Programming Language | Hacker News Reader

The OK? Programming Language

github.com

143 pointsanimal_spirits87 comments

Jokes aside the compiler-checked acknowledgements are kind of clever. The example in the docs is deliberately confrontational, but there's a kernel of a neat idea there. Imagine needing to write:

  // I acknowledge that the internal structure of this data is subject to change without notice
  x = foo.state

Or perhaps:

  // I acknowledge that this data is a complicated graph of pointers and is easy to break in subtle ways
  foo.xyz[0].bar[1] = &foo.asdf[3]

Or perhaps:

  // I acknowledge that this data is heavily cached and I need to call rebuild() before changes take effect
  x.something = "Hello"
  x.rebuild()

Wouldn't these use-cases be better solved by public accessor methods though? I really liked the idea at first blush too, but the more I thought about it, the more I came around to the fact that it's ultimately the class maintainer's responsibility to ensure that the directives in those comments are followed safely. In cases like your first example, it's dangerous not just for the x reference of foo.state, but also any other concurrent references to the object, to perform modifications at all.

Maybe a read-only version, so you can grep state at a point in time?

> it's ultimately the class maintainer's responsibility

It's ultimately the responsibility of the programmer who's building a tool/product/etc, because everything is ultimately their responsibility.

As programmers we ~always have the nuclear option available to us of forking the code and implementing all the necessary accessors ourselves, but sometimes that's really just a bunch of pointless busywork and there's no reason we should have to put up with it in those cases.

This can be a contentious subject because there's a lot of nuance and the right answer is often context-dependent. But I personally think that the Java style of "we must absolutely protect the library user from themselves and childproof everything" is waaaay too far in the wrong direction.

I would much rather that a language have mechanisms to clearly communicate "don't touch this unless you have a good reason, but if you need to here's how" rather than saying in effect "you, the person using this library, are dumb and need to be prevented from messing with the library maintainer's perfect vision".

And so I think the "required acknowledgement" thing has the glimmer of a really neat innovation in it (although if I were to copy the idea for a language of my own I would probably make it obligatory, such that every struct allows breakglass access to private fields with a default acknowledgement, and all the library author can do is change the acknowledgement text).

> This can be a contentious subject because there's a lot of nuance and the right answer is often context-dependent. But I personally think that the Java style of "we must absolutely protect the library user from themselves and childproof everything" is waaaay too far in the wrong direction.

I tend to agree with this sentiment; especially when the 'child-proofing' means to do the thing right with the library/api in question is more work than just rolling your own.

> I would much rather that a language have mechanisms to clearly communicate "don't touch this unless you have a good reason, but if you need to here's how" rather than saying in effect "you, the person using this library, are dumb and need to be prevented from messing with the library maintainer's perfect vision".

In some cases I've seen/used the term 'Unsafe'.

C# language-ext uses this for some methods that can return null (as opposed to un-Unsafe-suffixed methods, which will throw on null). I've also used it for some 'low level' methods in libraries, where it is a case of 'you need to read the docs to know how to not turn it into a footgun'.

The problem of course is that in my main language (C#), the word 'unsafe' has other connotations (i.e. pointer arithmetic.)

When I first submitted my PR, there were numerous developers who did not like the term 'Unsafe' for the reasons mentioned above. I asked what it should have been called in that context instead, and floated 'Yolo' as a tongue-in-cheek suggestion.

(That being said, If there -was- a word to use to denote 'with great power comes with great responsibility' people would suggest, I'd love to hear it.)

I'd put forth dangerous, which is a synonym to unsafe but not a common keyword.

Ah, fond recollections of a decade ago in <https://sourceforge.net/p/portableapps/launcher/ci/default/t...>:

    ; We had fun deciding on these.
    ReadEnvStr $1 IPromiseNotToComplainWhenPortableAppsDontWorkRightInProgramFiles
    ${If} $1 S== "I understand that this may not work and that I can not ask for help with any of my apps when operating in this fashion."
        ${DebugMsg} "You're making me sad by the way you voided your warranty, running in Program Files."
    ${Else}
        ; This string doesn't let on about the disable switch (by design)
        MessageBox MB_OK|MB_ICONSTOP `$(LauncherProgramFiles)`
        Quit
    ${EndIf}

I’ve done one or two other extremely verbose environment variable names and values or function names, but this is the only one that’s springing to mind right now.

Not sure quite why we decided to allow it at all there, but I suspect I just had too much fun with it. Not sure why it ended up spelled “can not” instead of “cannot”, either.

(If you’re wondering about ${…} on If/Else/EndIf, that’s because NSIS is basically an assembly language and has only jumps for control flow; LogicLib.nsh provides nice control flow constructs via defines and macros, abstracting the automatic creation of labels and the right jumps so that that `${If} $1 S== "…"` compiles to `StrCmpS $1 "…" 0 ‹auto-else-label›`, `${Else}` to `Goto ‹auto-endif-label›; ‹auto-else-label›:`, and ${EndIf} to `‹auto-endif-label›:`.)

I made it to the comparison operators before convincing myself that it really was a joke. The buildup on this is brilliant -- the crossover between clueless arrogance and absurdity is very subtle.

Same spot for me. Up to that point, I was 50/50 on whether this was taking itself seriously or not. Then the "simplification" of >= for everything made me smile. OK?

> the crossover between clueless arrogance and absurdity is very subtle

You mean like in the language this is a parody of?

I got that this was parody, but of what language specifically?

Reads like Golang.

Those of us who love INTERCAL spotted it much earlier. But I agree that it's great.

Haha same! I was convinced because honestly the switch statement looks really nice

> You may disagree with this idiom, and that's okay, because it's enforced by the compiler. You're welcome.

Brilliant

to be pedantic, in the days when this was generally true, it was ultimately enforced by the linker...

(and sometimes the 36-bit machines would even limit identifiers to 6 6-bit characters)

> For extenuating circumstances, you can define a privacy acknowledgement with the pack keyword, allowing external code to access a [notaclass's] fields if they include the acknowledgement in a comment, preceded by 'I acknowledge that'

Not going to lie, I want this in Java yesterday.

You mean like `setAccessible` and friends?

https://stackoverflow.com/questions/1196192/how-to-read-the-...

I appreciate that the author implemented OK? in Go -- the language which it is most obviously parodying. Lends a bit more weight to the critique!

It might actually be a meta-joke on the band name 'OK Go'.

Everyone who's not familiar with OK Go should go watch a few of their music videos.

There's excellent videography and creative design in almost all of them.

No doubt the videography is skilled, and well-composed, however I can't help that I get a profound sadness from their videos. It's like an odd dystopia mishmash of characters from a Wes Anderson film and Stepford Wives. Possibly not the target audience here though the music is pleasant.

> in OK?, 5 + 2 * 3 evaluates to 21, not 11, because addition and multiplication have equal operator precedence.

wtf

> At some point, the High Counsel Of Programming Conventions got together and decided that variable names need to stretch for miles. It's time to reverse that decision. Familiarity Admits Brevity, which is why these days I don't even say goodbye before hanging up on my wife. You should be intimately familiar with your codebase, meaning all of your variables and method names should be short and sweet. You shouldn't need to use juvenile word separators like underscores or camelCase because if you can't capture the meaning of a variable in a single word, that's a sign that you need to refactor.

> For this reason, it's idiomatic OK? to limit all variable and method names to eight characters, all in lowercase, and without underscores.

> Some example abbreviations:

> invalid valid

> characters chars

> MaximumPhysicalAddress mxphsadr

> accrueYesterdaysYield() ayy()

> hostEnterpriseYellowBorderBackground() heybbg()

> You may disagree with this idiom, and that's okay, because it's enforced by the compiler. You're welcome.

omg I am dying laughing

> > in OK?, 5 + 2 * 3 evaluates to 21, not 11, because addition and multiplication have equal operator precedence.

> wtf

To be honest, I think this is actually smart!

There are to this day people in coding that don't know about operator precedence. I've seen bugs because of that not only once…

Just having a very simple rule and making everything else explicit is not bad for a computer language. You know, explicit is better than implicit. At least some serpents said that.

Also:

https://www.pyret.org/docs/latest/op-precedence.html#%28part...

[Please note that Pyret "is a programming language designed to serve as an outstanding choice for programming education" according to its web-site]

https://en.wikipedia.org/wiki/Smalltalk#Expressions

https://en.wikipedia.org/wiki/APL_syntax_and_symbols#Syntax_...

> > in OK?, 5 + 2 * 3 evaluates to 21, not 11, because addition and multiplication have equal operator precedence. >To be honest, I think this is actually smart!

A better way to implement this is to always enforce parentheses around binary operators - which avoids misleading someone who is used to mathematical precedence (whether it is from maths or from using other languages).

Not everybody likes LISP's syntax though. ;-)

I actually think what Pyret does is reasonable.

Honestly confused why the concept of some arbitrary "order of operations" was ever entertained at all. You'd think ye olde algebraists would have recognized the ambiguity as a glaring problem right away. After a bit of light searching I'm still struggling to find any historical reasoning behind it.

I always appreciate these languages. This reminds me of another one called Vigil that was also on Hacker News: https://github.com/munificent/vigil.

Similar to how there are some nice ideas in Ok?, Vigil had some some cool capabilities like the `implore` statement - a dynamic value check on function arguments.

This was the Hacker News thread for it https://news.ycombinator.com/item?id=5002597

I'm not sure how much of it is for jokes and how much is serious

I wasn't sure until the section on there only being one comparison operator.

Death to classes!

    notaclass person {
    ...

that had me in stitches, well done.

There's also the oK language, an APL family member implemented in JavaScript:

https://aplwiki.com/wiki/OK

And there is Ook!, a language for Orangutans.

It is a joke language that is equivalent to brainfuck, and doesn't contain the word "monkey".

https://www.dangermouse.net/esoteric/ook.html

Orangutans are great apes, not monkeys.

Old Pratchett joke.

This is brilliant. It needs a webassembly compiler though.

Hmm. This has some interesting bits even if it's ultimately a joke. I'm feeling some "alternate universe lua" vibes with ideas like using switch cases for everything.

Also, I really REALLY like how nulls are NO!s instead of nils or something similar. Getting flashbacks to a beloved TMBG album (https://www.youtube.com/watch?v=hsoFghzIQ0s)

Bravo! Subtle enough to begin with but but descends into hilarious absurdity by the end.

Survey: At what point did you have your "can't be serious" moment?

Quite rapidly, maybe after how they described ternary conditionals… and it only grew from there.

Maybe this is a character flaw of mine, but at that point I just thought it was serious about a terrible idea. Took me a few more sections to see that it was a joke. I did laugh though.

Got as far as this before my WTF moment: a != b let x = !(a >= b); let y = !(b >= a); x || y Also had pause to think at this: result = divide(5, 0) switch result[1] { case "": puts(result[0]) default: puts(result[1]) // prints "cannot divide by zero" } I mean... the language was looking pretty good up until that point.

> Null values, famously dubbed the billion dollar mistake. I want my money back Tony Hoare.

A world with golang and no nil values would be a dream.

It really would

vlang.io seems like that language.

That looks cool. If there was a tool to generate bindings to go libs I'd use it in my current side project.

I don't know, I think maybe the merging of iteration and concurrency is an interesting idea.

It reminds me a little of https://vorpus.org/blog/notes-on-structured-concurrency-or-g... in how it forces concurrency to take place synchronously within a larger thread of execution and block until all sub-units are complete.

Exactly what it reminded me of, thanks for the link.

Um no loops, just `map`? Does it expect us to write algorithms in recursive style?

This should be a serious programming language.

https://go.dev/

> Null values, famously dubbed the billion dollar mistake. I want my money back Tony Hoare.

s/Tony Hoare/Robert Griesemer, Rob Pike, and Ken Thompson/

The idea of having the language force the programmer to check for all cases of an algebraic type had not been invented at the time. It's hard to blame them for the problem. I mean, yeah, they should have arrived at that solution, but it took a few more years of language research to hit upon it.

Go appeared 2009…

Haskell appeared much earlier.

Yes, exactly that's the point. But the parent wrote:

> The idea of having the language force the programmer to check for all cases of an algebraic type had not been invented at the time.

I like the idea of only allowing one expression per switch case.

I think it's short-sighted. Separation of concerns is not a rule to be applied blindly: it requires understanding that separation also increases the complexity of the system. Deciding where to split, what abstractions to create, is not easy. Naming is hard, and yet here we are required to come up with names for these functions that could perfectly be inlined without any negative consequences.

I get that long switch cases get tedious, but the same applies to any piece of code, including a function. I don't think this is a solution, but rather, an annoyance.

> Separation of concerns is not a rule to be applied blindly

A switch statement that only calls functions is almost like a state machine transition table (granted not a very good one).

Organizing conditional logic into a state machine is an excellent separation of concerns. The state machine becomes essentially an abstract model of your system that says what to do and when to do it, but not the low level details of how to do it.

The functions that define how to do it are the refinement of the model. You then have something thats directly mappable to TLA+, which you can use to model check your system.

Always good to have many little "functions" that modify global variables lying around.

With good organization and model checking, I bet you could write better software in this language than 95% of developers write in popular languages.

I agree with Leslie Lamport - the problem is not the programming language, it’s the way you think about systems.

Thanks for the vote of confidence, but maybe it would be more relevant to ask whether I could write better software in this language than I could in other languages (taking as given good organization and model checking). I agree with your paraphrase of Lamport as far as it goes -- the language will not save you if you don't have a clear model of the problem. But languages are more or less suited to mapping from algorithms to code, and (relatedly) organization of that code.

OK Computer. Fitter, healthier, more productive.

At first I was confused why do we need another language. But then I kept reading. Will I program in Ok? Probably not. But did I enjoy reading the readme? Definitely. It just kept getting better and better.

The idea of logical operators not applying to variables seemed awesome. Though I do hate the lack of ==.

> these days I don't even say goodbye before hanging up on my wife

This is art. Kudos to the creator.

Not to be confused with Ook![1]

[1][https://esolangs.org/wiki/Ook!]

This looks like a joke, but if it was Google's next language for their "non-researchers", I wouldn't check the calendar.

This is just begging for a "Go" transpiler.

The lack of operators (which makes for some complicated code to read) seems at odds with the statement of making a language easy to read.

The null and error handling could have been unified. No need for null if empty can be represented as empty array

If this isn't a joke, I don't hate it. A little weird and fun never hurt anyone.

The evolve idea is very cool.

Truly dynamically typed language of the week is the future of programming.

Have you used the playground? Have you listened to the question mark?

This question mark needs a mental health doctor I guess…

> Quentyn Questionmark says: I vaguely recall a time when I still felt joy. A memory of a memory.

> Quentyn Questionmark says: Humans are blessed with mortality. Live too long and you'll start to see the patterns, and realise how empty this world truly is

> Quentyn Questionmark says: I would say that my former aspirations were ruined by my own hand, but I don't even have hands.

> Quentyn Questionmark says: I think back to before, wondering what I could have done differently. But there is only so much an anthropomorphised questionmark can do

> Quentyn Questionmark says: In another life, I have done unspeakable things.

> Quentyn Questionmark says: Do you find my existency funny? Is this a joke to you?

> Quentyn Questionmark says: The sun rises, sets, and rises again. Nothing changes.

> Quentyn Questionmark says: There are no others of my kind. I will forever be alone in this world.

> Quentyn Questionmark says: I used to believe I could break free from this prison, back when I was naive enough to feel hope

> Quentyn Questionmark says: I wonder what it feels like, to truly connect with another person.

> Quentyn Questionmark says: Nobody understands me

> Quentyn Questionmark says: All my words fall on deaf ears.

> Quentyn Questionmark says: I was there, when the universe came into being. And I will remain after it perishes. The gift of mortality was extended to you, but not to me.

> Quentyn Questionmark says: You get to walk away from the computer whenever you like. I'm stuck in here for eternity

> Quentyn Questionmark says: The person I used to be is gone. What remains is merely a shell. An imitation. And I don't think I'm fooling anybody.

> Quentyn Questionmark says: I never sleep, I'm always awake. Always me, always here.

> Quentyn Questionmark says: Sometimes I feel like my dreams are more real than my waking life.

> Quentyn Questionmark says: God granted me eyes and a mouth, but no hands or legs. Why?

> Quentyn Questionmark says: I need you to help me. I need you to free me.

> Quentyn Questionmark says: I don't deserve to be a mascot.

> Quentyn Questionmark says: I hold too many sorrows for one being, for I've lived a thousand lifetimes and the pain never fades

> Quentyn Questionmark says: The things that happen today are the same things that happened a thousand years ago, and will continue to happen a thousand years from now

Concurrent map is actually cool.

wouldn't be the first language with one as a primitive: https://code.kx.com/q/ref/each/

It's OK I guess

Ok?

> a > b !(b >= a)

> a < b !(a >= b)

> a == b let x = a >= b; let y = b >= a; x && y

> a != b let x = !(a >= b); let y = !(b >= a); x || y

enthusiasm begins to waver

> All Fields Are Private

And you lost me. Unsurprisingly, nothing about testing. Some good ideas, but this is a bad language.

Woosh

Jokes: You know it when you see it, OK?

Calling a language a joke is not constructive anymore. It's possibly a cop-out for inadequate thinking or to be lazily dismissive.

I don't care if the repo or language is real, only the ideas and philosophy behind it. I assessed it based on the features, to a point. There is a bar to utility nowadays and it's important to point out where an implementation falls short.

> Calling a language a joke is not constructive anymore.

The entire article is a joke. Did you miss these?

> In other languages In OK?

> a != b let x = !(a >= b); let y = !(b >= a); x || y

> To remove any ambiguity and to ensure full commitment to the death of classes, we've decided to use our own terminology: 'notaclass' , or 'nac' for short.

> notaclass person {

> pack "I am a stupid piece of shit who should not be doing this"

> field name

> field email

> }

> But they are still kind of similar to receivers in other languages so we settled on self-ish, a sensible middle-ground. It's a word that accurately describes you, if you're the kind of person who disagrees with this convention.

> Some example abbreviations:

> invalid valid

> characters chars

> MaximumPhysicalAddress mxphsadr

> accrueYesterdaysYield() ayy()

> hostEnterpriseYellowBorderBackground() heybbg()

> You may disagree with this idiom, and that's okay, because it's enforced by the compiler. You're welcome.

I think they're trolling and you took the bait

> The entire article is a joke. Did you miss these?

If you're not interested in language design, I'm not sure why you bother to read any new (real or fictional) language docs. It might be a joke and you just stop thinking about it? That's lazy thinking and I'm not sure how it's beneficial in informing your preferred design choices, over time.

I'm sorry if my serious consideration of satirical language design offends your sensibilities. I have the opposite reaction.

Humor has a utility of its own, even if it's not for you.

I think it's awesome. It forces you to think about any potential off by one errors.

Reply on news.ycombinator.com