[HN Gopher] The OK? Programming Language
___________________________________________________________________
The OK? Programming Language
Author : animal_spirits
Score : 67 points
Date : 2022-08-29 17:26 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| padjo wrote:
| Bravo! Subtle enough to begin with but but descends into
| hilarious absurdity by the end.
| pavlov wrote:
| There's also the oK language, an APL family member implemented in
| JavaScript:
|
| https://aplwiki.com/wiki/OK
| GuB-42 wrote:
| 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
| person22 wrote:
| 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.
| [deleted]
| [deleted]
| livinglist wrote:
| This should be a serious programming language.
| zeckalpha wrote:
| https://go.dev/
| cheriot wrote:
| > 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/
| djhaskin987 wrote:
| I don't know, I think maybe the merging of iteration and
| concurrency is an interesting idea.
| wgd wrote:
| 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.
| [deleted]
| AdamH12113 wrote:
| 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.
| function_seven wrote:
| 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?_
| Tao3300 wrote:
| > 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.
| nemo1618 wrote:
| 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!
| Quekid5 wrote:
| It might actually be a meta-joke on the band name 'OK Go'.
| robga wrote:
| OK Computer. Fitter, healthier, more productive.
| cheriot wrote:
| > 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.
| redbar0n wrote:
| vlang.io seems like that language.
| topicseed wrote:
| It really would
| wgd wrote:
| 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()
| miamibougie wrote:
| 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?
| wgd wrote:
| > 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).
| topaz0 wrote:
| The evolve idea is very cool.
| SketchySeaBeast wrote:
| This is just begging for a "Go" transpiler.
| [deleted]
| matthewfcarlson wrote:
| 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 ==.
| TeaDude wrote:
| 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)
| coldtea wrote:
| It's OK I guess
| phanimahesh wrote:
| This is brilliant. It needs a webassembly compiler though.
| tffcccdredf wrote:
| pyrolistical wrote:
| The null and error handling could have been unified. No need for
| null if empty can be represented as empty array
| blue_pants wrote:
| I'm not sure how much of it is for jokes and how much is serious
| MonkeyMalarky wrote:
| I wasn't sure until the section on there only being one
| comparison operator.
| maxique wrote:
| > You may disagree with this idiom, and that's okay, because it's
| enforced by the compiler. You're welcome.
|
| Brilliant
| 082349872349872 wrote:
| 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)
| dqpb wrote:
| I like the idea of only allowing one expression per switch case.
___________________________________________________________________
(page generated 2022-08-29 23:00 UTC)