Unique Software and Insidious Optimizations: Abandoned Fields are Fertile Ground for Novel Research

The purpose of this thread is discussing software which solves problems not recognized as such, or which takes issues with aspects of the current computing culture taken for granted. An insidious optimization is such an optimization that ceases to be viewed as one. An insidious optimization is insidious in how it limits thought, especially to those thinking after one is introduced. An insidious optimization is such an optimization which is neither necessary nor was necessarily always present with regards to its topic. It limits thought by contributing unnecessary constraints and assumptions; with an insidious optimization, people will simply not see alternations or will even have difficulty understanding alternations could exist. It stunts a mind. There exist many insidious optimizations in that young field of automatic computing. I'll start by introducing both of my primary projects, Meta-Machine Code (MMC) and Elision. My work is available over the WWW and also Gopher. The MMC is a hardcore machine code hacking tool I've discussed at some length in the machine code thread: >>43 I envisioned a machine code an assembler couldn't reasonably serve, and noticed using text and batch tools to write machine code is mistaken and wasteful. The MMC is an interactive tool, this alone preventing many errors, in which each action is bound to a key. So, rather than writing a statement, one simply presses a key and is asked questions. I'll let these articles explain the rest: http://verisimilitudes.net/2017-07-07 http://verisimilitudes.net/2020-07-07 http://verisimilitudes.net/2020-12-26 The latter two detail the two latest implementations of this design, with the last being the best; I went from storing the program as it is for the machine, along with metadata in parallel arrays, to using a doubly-linked list holding tagged data instead and only pressing it to its numerical representation when saving. This means it's much harder to accidentally write a bug and also makes the MMC easier to write. I don't currently target a real machine code, but primarily CHIP-8, although I intend to do so soon enough. I want to do all of my programming in such tools, instead of using a text editor, and machine code was a good vehicle for experimentation in this. The Elision system comes from something similar. Why should anyone use the same tools for writing programs and human language? I trace this back to the teletype using character sets, which predates automatic computers. Storing text character-by-character is very inefficient. For human language text, words are being encoded, not random sequences of characters. It would be simple to store these words and their variants into a dictionary, internally represented there as character sequences, to represent text as indices into this dictionary. A machine from thirty years ago could do this more than efficiently enough, but historical matters get in the way. I've done much less work on this than the MMC, only really starting with this year, but here are some relevant articles: http://verisimilitudes.net/2018-06-06 http://verisimilitudes.net/2019-11-22 http://verisimilitudes.net/2020-06-18 http://verisimilitudes.net/2021-05-05 The second and fourth are related, in that the second is a detailed criticism of Unicode, and the fourth details general programming errors, with a partial emphasis on characters. To prevent this post from being bereft of code, follows are the contents of a basic APL implementation (AGPLv3) of an Elision targeting toki pona, a rather useless constructed language which is in any case suitable for such experimentations: http://verisimilitudes.net/2021-09-21 d←'aeijklmnopstuw ' ⍝ The d is the character domain of toki pona, and the tp is the word dictionary. tp←(1⍴'a') 'akesi' 'ala' 'alasa' 'ale' 'ali' 'anpa' 'ante' 'anu' 'awen' (1⍴'e') 'en' 'esun' 'ijo' tp←tp,'ike' 'ilo' 'insa' 'jaki' 'jan' 'jelo' 'jo' 'kala' 'kalama' 'kama' 'kasi' 'ken' 'kepeken' tp←tp,'kili' 'kin' 'kiwen' 'ko' 'kon' 'kule' 'kulupu' 'kute' 'la' 'lape' 'laso' 'lawa' 'len' 'lete' tp←tp,'li' 'lili' 'linja' 'lipu' 'loje' 'lon' 'luka' 'lukin' 'lupa' 'ma' 'mama' 'mani' 'meli' 'mi' tp←tp,'mije' 'moku' 'moli' 'monsi' 'mu' 'mun' 'musi' 'mute' 'namako' 'nanpa' 'nasa' 'nasin' 'nena' tp←tp,'ni' 'nimi' 'noka' (1⍴'o') 'oko' 'olin' 'ona' 'open' 'pakala' 'pali' 'palisa' 'pan' 'pana' tp←tp,'pi' 'pilin' 'pimeja' 'pini' 'pipi' 'poka' 'poki' 'pona' 'pu' 'sama' 'seli' 'selo' 'seme' tp←tp,'sewi' 'sijelo' 'sike' 'sin' 'sina' 'sinpin' 'sitelen' 'sona' 'soweli' 'suli' 'suno' 'supa' tp←tp,'suwi' 'tan' 'taso' 'tawa' 'telo' 'tenpo' 'toki' 'tomo' 'tu' 'unpa' 'uta' 'utala' 'walo' 'wan' tp←tp,'waso' 'wawa' 'weka' 'wile' (0⍴0) (0⍴0) (0⍴0) (0⍴0) ⍝ Transform a toki pona language string to its Elision representation, but with no magnitude limits. ∇ e←elision s;t;a;⎕IO ⍝ The first line ensures the parameter adheres to that domain of the function. ⎕IO←0◊s←,s◊⎕ES 0⊃(⍲/s∊d)/⊂'The argument contained characters not part of toki pona.' t←(s≠' ')⊂s◊a←(128=tp⍳t)/t◊→3⍴⍨0=⍴a◊a←a[d⍋⊃a] ⍝ Separate words. Create that auxiliary dictionary. e←(⊂a),t⍳⍨tp,a ⍝ Combine the dictionaries, search them again, and fuse this for that final result. ∇ Follows is an example from the article; for details, read the entire article: r←elision 'mi pana e pelisimilitu'◊r ⍝ I exude verisimilitude. ┌5────────────────────────────┐ │┌1─────────────┐ 54 80 10 128│ ││┌12──────────┐│ │ │││pelisimilitu││ │ ││└────────────┘│ │ │└∊─────────────┘ │ └∊∊───────────────────────────┘ ¯1↓1↓⍕(tp,↑r)[1↓r] ⍝ I should've known to use ⍕ much earlier; the two drops merely remove spacing. ┌22────────────────────┐ │mi pana e pelisimilitu│ └──────────────────────┘ I've dedicated much of this year to mulling over Elision and playing with it, to some amusing realizations. Firstly, starting with toki pona hid more complexity of real languages than first realized, primarily regarding declensions and conjugations; for a language such as English, this greatly expands the size of the dictionary, simply enumerating them is difficult, and English is of course a language in which there are sometimes multiple and incompatible ways to do this for a single word. Secondly and perhaps ironically, my resuming learning Latin with this year has allowed me to see an even nicer form of Elision, in which semantic information is paired with each word, rather than simply interning it; Latin is so regular that storing each form is unnecessary, and instead a word could be paired with a code that describes its declension or conjugation, with the system using this when necessary, greatly reducing the amount of information to store and manipulate. This thread is intended to be general beyond my work, because I don't want a thread dedicated solely to myself. However, before posting about some work here, do make an effort to ensure its novelty; none of the following are relevant here, for examples: some implementation of some standard anything involving the WWW a text editor something that solves a problem entirely created by other software This is a thread for taking issue with supposed-fundamentals, so treat it like one. I'd argue common sense would be sufficient, but anyone who has learned enough about computing knows common sense is non-existent. A project such as Urbit may seem unique, but doesn't go far enough for my tastes; keeping ASCII seems silly in light of my work, doesn't it? Furthermore, reading has shown me that Urbit is simply an Applicative State Transition system (AST) as described by John Backus, but with a pathetic language behind it; the MMC design can also be considered an AST, however. I'm not asking for any help, nor do I want any; I only want to discuss my work. The closest thing to help I'd want is for others to spread my work for me in venues which I don't visit. I made this image, lacking a better choice.

>>28919 If I were a psychiatrist i'd diagnose you as schizophrenic. You're probably either a genius or extremely daft

>>28919 >Meta-Machine Code Have you released the code for your MMC?

>>28930 http://verisimilitudes.net/2020-07-07 http://verisimilitudes.net/2020-12-26

I think I see the common thread between the two examples you give: a domain mismatch, where the technology used to manipulate a thing is not made of the same primitives as the thing itself. A technology that fits its problem domain well can be expected to accomplish two things: first, it should be efficient, by allocating resources only as needed; second, it should disallow elements which are foreign to the domain. An example of the latter: a program is conceptually made of things like expressions and statements, not characters; if a tool allows typos to be introduced into a program, the tool doesn't fit the domain well. On the topic of natural language, I don't think the latter is possible at all, because the domain is open-ended. Vocabulary, of course, is always subject to additions (also in non-obvious ways: a misspelling can be made on purpose for some effect), but grammar also evolves or can be subverted on purpose. What remains then is resource efficiency. Your Elision system takes advantage of the fact that speech, although infinitely complex and varied, most commonly adheres to a finite set of words and rules. It optimises for the encoding of the common patterns, while keeping the door open for variation by means of the 'auxiliary dictionary' (which every non-trivial text would need to have attached to itself). As criticism, I would say that your system is tightly coupled to the notion of word, which is ambiguous and varies across languages, yet you never define what you mean by it. I argue that 'word' itself is an insidious optimisation which encumbers thought about language, but I reckon that your system makes it easier to avoid its common pitfalls. Those pitfalls include: - 'word' as what comes between spaces: your system decouples words from separator characters; it makes word count available for languages that don't use such characters, and allows 'grand piano' to be stored and counted as a single word. Some words, like articles or pronouns, are required by grammar and don't contribute to text complexity; if your dictionary stores word metadata, a word-counting program could skip such words and produce a more meaningful metric - 'word' as a sequence of characters: sometimes several words have the same shape, and sometimes one word can be inflected and have several shapes. True language-based search would allow things like searching for 'tread' (the noun, not the verb) or searching for a word in any inflected form. Your system directly supports or makes it easier to implement these features I was originally very sceptic about your scheme, but now I see its advantages. A final word of advice: don't work only on languages like Latin or toki pona - the very unfair advantage that no one actually speaks them allows them to maintain an elegance and regularity that worldly languages can seldom preserve.

>>28919 >targeting toki pona, a rather useless constructed language ala. toki pona li jo e kepeken mute. sina sona ala sona e toki pona?

>>28921 good thing you're not a psychiatrist

>>28919 > So, rather than writing a statement, one simply presses a key and is asked questions. This is a cool idea. But it's pretty hard to figure out what you're doing here. I have no idea what I'm looking at. I feel like this is written for yourself and not an audience. Imagine you're writing marketing copy for a dev tool or something. >>28919 >a word could be paired with a code that describes its declension or conjugation, with the system using this when necessary, greatly reducing the amount of information to store and manipulate A word by itself with no context is clearly more meaningful to a computer or to a human than just characters, but it's not some complete form or something.. There's still much room for ambiguity and language games. However "programming with verb tenses and noun declensions" is another cool idea. >>28919 >English is of course a language in which there are sometimes multiple and incompatible ways to do this for a single word I'm pretty sure this is every language that is actually used by humans! Maybe I'm missing something.

I have a pet peeve with common contemporary OSs which may fit the spirit of this thread. I put it this way: they don't have a human-intuitive concept of 'task'. They understand things like 'processes' instead, and the two don't map over well. It'd be nice to approach a computer as in old science fiction movies and instruct it to perform a series of tasks. For example, at work I frequently find myself wishing to say 'computer, shut down as soon as this software update is finished' - but the updating program has no allowance to set up a post-update action, nor does the shutdown program have any notion of what other programs are doing and when they'll be done. Other times I find myself wanting to perform several tasks in sequence, maybe because they compete for the same resource and would step on each other and take longer if done in parallel. For example: - CPU-heavy video conversions - loading web pages over a slow link (Tor) - copying many files to the same device There are two things wrong here. First, I shouldn't have to worry about performance - the computer should figure it out and run my tasks in the most efficient way. Second, I don't have any general way of putting a task into the queue - each program has a different interface, and they don't coordinate with each other. There is no way to say, 'program A, do this after program B is done doing that'. If the task can be done with an invocation of a non-interactive CLI program, I'm relatively in luck, because my 'task' does indeed match up with a 'process'. At least in this case I can use my shell to input a sequence of commands, but there are shortcomings: - if I made a syntax error in the third command, I won't know until the first two have run, so I can't leave my computer unattended and trust to have a result when I'm back - if I set a task running and then think of some other tasks, I have to wait for the first to finish before I request the others If the task is to be done with an interactive program, it is up to the developers whether you can enqueue tasks within it, and for several programs to coordinate is out of the question. I'm not aware of many software projects that address this situation. Here's what I can think of: - I understand in Plan9 programs expose a filesystem API to send them requests - that'd make it easier for them to communicate with each other, but you still depend on what each particular program chooses to expose - the PCManFM and SpaceFM file managers, by default, put all file operations in a queue and run them in sequence. Great if that happens to be what you need - a couple of projects in my repos allow you to enqueue commands and have them run in sequence: nq (https://git.vuxu.org/nq/about/), task-spooler (https://viric.name/soft/ts/). You still need to remember to prefix the first task with the queue command, although maybe that could be automated in your shell - for the case when I don't remember to explicitly enqueue a command, yet I want something else to run when it's finished, I wrote a simple program that takes a number of PIDs and blocks until all the corresponding processes are finished

>>28951 > For example, at work I frequently find myself wishing to say 'computer, shut down as soon as this software update is finished' - but the updating program has no allowance to set up a post-update action, nor does the shutdown program have any notion of what other programs are doing and when they'll be done. ??? su -c 'pacman -Syu; poweroff'

>>28953 He probably means "after it was launched". You use `while ps -A -ocomm= | grep -qFx myprogram; do sleep 1; done; poweroff`. It'd be retarded to manually add hundred of callbacks or events to absolutely every program. >>28951 >Other times I find myself wanting to perform several tasks in sequence, maybe because they compete for the same resource and would step on each other and take longer if done in parallel. For example: > >- CPU-heavy video conversions >- loading web pages over a slow link (Tor) >- copying many files to the same device > What are nice and ionice? >There are two things wrong here. First, I shouldn't have to worry about performance - the computer should figure it out and run my tasks in the most efficient way. What you want is possible, but not automated, I think. It is a piece of cake to do so: depending on the way you launch program, just use a script to match the program name and launch it with the appropriate nice/ionice value; that way, you just have to flag the few soft-realtime programs you have. For example, my music player is launched via `sudo ionice -c1 sudo -u $USER player`.

Related to my language modelling is the idea for a forum built around it. I won't discuss it much, but imagine how much nicer it would be to have a machine-level understanding of which messages reference which, built out of commands and not chevron syntax that can be typed incorrectly. Perhaps most importantly, consider the forum communicating to the client with normal messages that aren't parsed to divine meaning; consider this: new code: 29 However, consider a system where those two words and their trailing punctuation fit in two thirty-two bit words; consider that the system wouldn't parse them, but simply know of the message ahead of time, and compare verbatim templates for the context until it determines which one matches; consider that new code of 29 isn't a number to be parsed, but inlined in the message as a known number. Lastly, consider that what I've shown is merely how the message could be displayed to a human. The only disadvantage here is the inability to change message text, not that it would be a great loss. This is a true format for intercommunication, trivial for machines and with no parsing, yet able to be displayed to a human without issue. >>28947 >I think I see the common thread between the two examples you give: a domain mismatch, where the technology used to manipulate a thing is not made of the same primitives as the thing itself. I'm attacking both ends, yes. I see using character-by-character editors as good for neither programming nor writing human text. >if a tool allows typos to be introduced into a program, the tool doesn't fit the domain well. That's a good way to think of it. The MMC enables me to avoid many kinds of errors an assembler can only fail on, such as using a register number which doesn't exist, simply by disallowing them entirely. >What remains then is resource efficiency. Your Elision system takes advantage of the fact that speech, although infinitely complex and varied, most commonly adheres to a finite set of words and rules. Yes, and this is the same thing a character-by-character system takes advantage of, that writing a letter one way or the other generally doesn't matter, and they can be considered an ideal. I'd like to have a text system that doesn't restrict the symbols one may use, but that will necessarily come later. >It optimises for the encoding of the common patterns, while keeping the door open for variation by means of the 'auxiliary dictionary' (which every non-trivial text would need to have attached to itself). I'm not certain every non-trivial text would need it. Regardless, there are interesting applications once the primary dictionary be large enough. Consider a Robot 9000 system that can't be so easily fooled, because it will only use words it knows for calculating the unique character of a message; I'd like to experiment more on that later, but I need a working system first. >As criticism, I would say that your system is tightly coupled to the notion of word, which is ambiguous and varies across languages, yet you never define what you mean by it. Different languages will have different ideas of it. This is from the fifth article in the opening post: >In my conclusion, Unicode is a very poorly-designed character set, which is fundamentally misguided. I dislike ASCII, in part because of its control character class which behaves differently from every other character, and yet ASCII is tolerable if for no other reason than it is simple. Proper system design takes pain unto itself to eliminate edge cases. A proper text system would localize language edge cases, so that in a language in which the notion of a character makes sense the notion could be used; in a language with the notion of one-to-one upper and lower cases, that could be employed; and in a language where all text follows a certain flow, that flow could be used without issue, as three examples. The Unicode approach seems to be to pour all edge cases into a single container, and then expect that the programmer will handle every single one, but this is unreasonable and doesn't happen in practice, leading to broken systems or those which only accept a subset of Unicode. >- 'word' as what comes between spaces: your system decouples words from separator characters; it makes word count available for languages that don't use such characters, and allows 'grand piano' to be stored and counted as a single word. Some words, like articles or pronouns, are required by grammar and don't contribute to text complexity; if your dictionary stores word metadata, a word-counting program could skip such words and produce a more meaningful metric I don't intend to allow spaces or other such things in a word. For English and other living languages, I believe it's important to maintain the impossibility of homographs. For Latin, I quite like the idea of no space being one punctuation option, to allow the combination of a prefix and suffix, such as AB and ĪRE into ABĪRE, without needing to explicitly store the combination; much of this is due to the fact that I could expect a higher class of user for Latin, and that it's much less of an issue for Latin anyway; one way to attack homographs is by indicating it through other means, such as underlining combined words, but this is by that point a more specialized system. I could use color, font, and other such things for so many purposes in a dedicated Latin viewer, such as gender and word class. I don't intend to let the stupidity of the world lessen my work, but staving off this issue for English at as high a layer as possible is still a good idea. Word count would be constant time, but a word count that elides certain classes of words, while linear in time complexity, could be useful, yes. I've entertained the idea of an even higher system that adds rigidity to sentence structure and so on, but that approaches something somewhat silly. >- 'word' as a sequence of characters: sometimes several words have the same shape, and sometimes one word can be inflected and have several shapes. True language-based search would allow things like searching for 'tread' (the noun, not the verb) or searching for a word in any inflected form. Your system directly supports or makes it easier to implement these features I've decided such a thing would require some human intervention for correct results, having thought about it a great deal with Latin, but yes. >I was originally very sceptic about your scheme, but now I see its advantages. A final word of advice: don't work only on languages like Latin or toki pona - the very unfair advantage that no one actually speaks them allows them to maintain an elegance and regularity that worldly languages can seldom preserve. I know. >>28948 I only understand some of that. I've a much easier time learning and remembering Latin, despite its much higher complexity, because I know it's useful, and this is reflected in the world around me constantly. However, toki pona is so useless I can't bring myself to remember much of it at all by now; I know the word for bread is derived from the Latin PĀNIS. >>28950 >I feel like this is written for yourself and not an audience. No, that was the first version of the article. It has been rewritten several times since. I'd include key press information in the video, but know of no software to make the display for me. >However "programming with verb tenses and noun declensions" is another cool idea. Well, this hits on something else with which I want to play later. >I'm pretty sure this is every language that is actually used by humans! Maybe I'm missing something. What's the plural form of penis? >>28951 This could be solved by the ability to treat a task as a variable in an equation, of course with the ability to modify an equation already partially-evaluated. I believe a system that has a good base would provide all of this and more, trivially. There should be more specialized hardware, onto which to offload or with which to have a real-time system that prevents some of those issues. Read this, from an acquaintance: http://www.loper-os.org/?p=284

>>28953 >>28955 Every time I've tried to use nice or renice, which want root privilege to raise priority, they barely work. A music player given full priority still stutters, or a large program still weighs down everything else. It's pathetic. Perhaps I should've used ionice, which OpenBSD doesn't seem to have. I do know UNIX works great, so long as it has access to massively more resources than are required for whatever task with which it be limping along and carrying out. >It'd be retarded to manually add hundred of callbacks or events to absolutely every program. I agree. Perhaps there could be a general program that interfaces with others, and perhaps returning an octet isn't the ultimate interface carved into rock it may seem to be. Read this: https://ngnghm.github.io/blog/2016/01/03/chapter-8-inter-process-communication >Now, on Human computer systems, copy-paste requires every participating application to specially implement large chunks of graphical interface support. Every application then becomes somewhat bloated, having to include large graphical libraries (which in modern systems can happily be shared between applications); but also having to properly initialize them, follow their protocols, abide by the strictures of their event loop, etc. They have to be able to negotiate with the clipboard server the kinds of entities they can copy and paste, and/or convert between what the server supports and what they can directly handle. This architecture where all features are implemented at the same level of abstraction contributes significantly to the complexity of applications; applications are therefore hard to reason about, brittle and insecure. The overall graphical environment will in turn inherit the unreliability of the applications that partake in it. And despite all this complexity, often some application will fail to support copying for some of the information it displays (e.g. an error message); the feature is then sorely missed as the user needs to copy said information by hand, or falls back to some low-level means of information capture such as screen copy (or memory dump, for more advanced developers). >An interesting exception to the rule of the above paragraph is the case of “console” applications: these applications display simple text to a “terminal emulator” straight out of the 1970s, at which point all the output can be copied for further pasting. The terminal emulator thus serves as the meta-program responsible for presentation of the application output, and handling copy-paste. This comes with many limitations: only plain text is supported, not “rich text”, not images; lines longer than the terminal size may or may not be clipped, or have an end-of-line marker or escape character inserted; selecting more than a screenful may be an issue, though you can sometimes work around it by resizing the terminal or by switching to tiny fonts; standard output and error output may be mixed, and interspersed with output from background programs; layout artifacts may be included (such as spaces to end-of-line, or graphic characters that draw boxes in which text is displayed); etc. Still, the principle of a meta-program to handle display already exists in some Human computer systems; its protocol is just limited, baroque and antiquated. >What you want is possible, but not automated, I think. Think about that phrasing. I recently saw some idiot write this, about one of the many flaws in UNIX: >If I could rewrite the universe ... We can rewrite the universe, to elide this vile filth. Now, as stimulating as discussing semicolons or why nice values range from -20 to 19 or 20 may be, this isn't the thread for troubleshooting UNIX nonsense.

>>29039 You use OpenBSD and rant about bad performance? Are you retarded, mate?

>>29041 Currently, I'm using GNU/Linux, but I've used OpenBSD, and still continue to on another machine. People have a warped view of how powerful modern hardware is, because of inexcusably-inefficient software. A machine that can do billions of operations per second isn't slow, and never should be considered slow, meaning the software that makes it slow is inexcusable. Regardless, this isn't related to the thread topic, and don't spill the soykaf.

>>29038 >I only understand some of that. I've a much easier time learning and remembering Latin, despite its much higher complexity, because I know it's useful, and this is reflected in the world around me constantly. However, toki pona is so useless I can't bring myself to remember much of it at all by now; I know the word for bread is derived from the Latin PĀNIS. It translates to literally "negative. toki pona posseses many uses. Have you learned toki pona?" Though politeness is implied so a better translation for "ala" in this context is "I disagree" not just "negative."

>>28919 A thread is what it is, not what a sentence at the bottom of the OP says it is. >It would be simple to store these words and their variants into a dictionary No it wouldn't, you can't enumerate the words in any language. And if it works such that you don't need to (i.e. it's a parameter of the encoding), you just have a compression scheme. The posts in this thread are pretty random, so I'll just say some stuff about ideas I see. Sometimes, bad/imperfect ideas build up a lot of inertia. Wisdom is knowing which of these are worth fighting over. Writing programs using text will at some point be seen as we see using punchcards today. Language is complicated, fractally, and evades all models we can come up with. As far as the first point, it'd be a good idea to make current OSs usable before trying to make a revolution. Most of the time, it's not about what you're doing, but how well you're doing it. Right now it's being done badly. The most valuable work I see done is basically peeling the crust from existing things. Otherwise you basically have a kind of haze where you can't tell the inherent properties of something from the emergent properties. The history of unix has shown that a lot of things people thought were things inherently wrong with unix were just incedental, and we've fixed them now. Many others are yet to be fixed, and many others are in the grey area where a solution exists but is still being developed / isn't stable yet. Some things *are* inherent though. Taking arguments to a program as argc and argv is pretty stupid, really. Still, it's the least of our worries. I *want* that to be the most important problem to solve. The world will be good when the things that are wrong with computers are all on the level of "we take arguments to programs as a string and return an int". >>28951 You can sort of do these kinds of things, it's just a pain. Run your shell command through a static verifier, loop until the PID of the process you want to wait for is empty, etc etc Obviously this isn't good, but it shows how it doesn't conflict with what exists. You could make a better shell that lets you do these things, probably more robustly than what I could come up with in 10 seconds on a lainchan thread.

>>28919 Is your Elision system mainly focused on non-synthetic languages? It seems difficult to use an enumeration scheme like you suggest for synthetic languages where there isn't a fixed set of words.

>>29068 >A thread is what it is, not what a sentence at the bottom of the OP says it is. We'll see about that. >No it wouldn't, you can't enumerate the words in any language. I disagree. Regardless, it's possible to enumerate the words in any writing. A writing which is composed primarily of nonstandard words isn't written in any existing language. An English document must be primarily written in English. >And if it works such that you don't need to (i.e. it's a parameter of the encoding), you just have a compression scheme. Elision has some characteristics of a compression scheme, yes. Recognize that a higher-level representation is necessary for excellent compression. Compare any music compression to MIDI. Compare vector and raster images. >Sometimes, bad/imperfect ideas build up a lot of inertia. Wisdom is knowing which of these are worth fighting over. I already cover this idea. I could've had my fifteen minutes of fame come and go already had I decided to do some functional programming work or something else popular, but my work would've been incorporated into Haskell or whatever and that would've been it. Abandoned fields are fertile ground for novel research. It's relatively easy to create new work in places with which most people aren't concerned. >Writing programs using text will at some point be seen as we see using punchcards today. Well, not with this attitude. UNIX has survived fifty years, fifty years too many, and in the face of better systems that just happened to be too expensive or which required more specialized hardware or due to some other irrelevant issue. Who's to claim it won't remain like any other terrible idea? >Language is complicated, fractally, and evades all models we can come up with. Oh, that's except for this model we're using right now, right? Language can't possibly be modelled, except through a character-by-character system, right? It ended there, over a century ago? >As far as the first point, it'd be a good idea to make current OSs usable before trying to make a revolution. Oh, but I don't think they can be made usable, so I won't bother, as so many hopeful fools have. >Most of the time, it's not about what you're doing, but how well you're doing it. >Right now it's being done badly. Current systems are fundamentally flawed. People still use languages that allow for basic errors, and not just for fun, but for work in critical systems. >The most valuable work I see done is basically peeling the crust from existing things. Well, what a safe view this is to hold. >The history of unix has shown that a lot of things people thought were things inherently wrong with unix were just incedental, and we've fixed them now. No, it's still terrible, and can't be fixed. What's good isn't new, and what's new isn't good. >Many others are yet to be fixed, and many others are in the grey area where a solution exists but is still being developed / isn't stable yet. I'd rather waste my life working on original ideas of mine than waste it patching holes in the expired work of some intelligent idiot dipshits. >I *want* that to be the most important problem to solve. I want a future in which correcting a poor model isn't considered research. >The world will be good when the things that are wrong with computers are all on the level of "we take arguments to programs as a string and return an int". It's queer to not think of these flaws as connected in any way. >>29070 Yes. The idea of an auxiliary dictionary is there to allow for words not in the primary dictionary, and it's necessary to avoid unduly constraining language and thought. Consider this post. At a glance, the words UNIX and dipshits likely wouldn't be in the primary dictionary, and MIDI would be an acronym composed out of its base words and made to display as an acronym. Elision is really just taking the current approach further. I believe in extreme views, and see character-by-character systems as an untenable middling position. Language is constrained by character sets as well, and enough decades of that really starts to cause decay, which is a problem I want to fix as well.

>>29079 >>Language is complicated, fractally, and evades all models we can come up with. >Oh, that's except for this model we're using right now, right? Language can't possibly be modelled, except through a character-by-character system, right? It ended there, over a century ago? I think you're gravely misunderstanding what that lain is saying. Character encodings aren't a model of language, as evidenced by the fact that they have no concept of grammar. They're a model of writing - yes, a restrictive, oversimplified model, we've been through that already. The point being made, as I understand it, was not a defeatist defense of the statu quo, but a cautionary tale to any fools that might come up with a more efficient way to encode text and believe that it buys them a computer model of human language for free.

>>29094 We disagree on whether character sets constitute a model of language or not. The modelling idea came later; with English, I simply recognized Elision as a more efficient model for manipulating text. It's with Latin that I realized adding more gave unto me a true language model, and it's not free, because no machine could perfectly translate a Latin text from its character-by-character representation to Elision, due to ambiguities that require intelligence capable of grasping context to resolve them; there's a finite amount of classical Latin text, and a modern editing tool could be made to make this easier to add to any newer writings, so it doesn't much worry me.

I feel silly, having noticed an error in the code I placed in the opening post, ironically in its sole line of error checking. This goes to show no one, sans myself, is running it anyway. My first mistake was trying to be clever by replacing negation of AND reduction, ~∧/, with NAND reduction, ⍲/ and, since it happened to work on every string I gave, I didn't look into it carefully enough, but it can give different answers based on the length of the string. I should've noticed this, but I also should've just used the earlier code. This then hid the fact that the unconditional ⎕ES code doesn't actually work; I should've just put up with the conditional code. I was much more thorough with checking everything else, although I may want to review it again later now. Perhaps this is what I get for adding explicit error handling to an APL function instead of simply designing it to explode on invalid input. Here's the corrected function: ⍝ Transform a toki pona language string to its Elision representation, but with no magnitude limits. ∇ e←elision s;t;a;⎕IO ⍝ The first line ensures the parameter adheres to that domain of the function. ⎕IO←0◊s←,s◊→2⍴⍨(∧/s∊d)◊⎕ES 'The argument contained characters not part of toki pona.' t←(s≠' ')⊂s◊a←(128=tp⍳t)/t◊→3⍴⍨0=⍴a◊a←a[d⍋⊃a] ⍝ Separate words. Create that auxiliary dictionary. e←(⊂a),t⍳⍨tp,a ⍝ Combine the dictionaries, search them again, and fuse this for that final result. ∇ While this is pathetic, at least I noticed and corrected it, and this program is clearly a toy. As I already noted in the now-corrected article, even APL gets in my way when it comes to implementing this. Ada will be a better language for implementing an Elision, due to its more explicit behaviour, but I also want to reduce all algorithms used in Elision to their bare minimums, to help prevent mistakes such as this, and to make it easier to port to many environments; only the tables will be allowed to be interesting, not the algorithms. At its core, I want almost nothing but array indexing. >>28948 r←elision 'ala toki pona li jo e kepeken mute sina sona ala sona e toki pona'◊r ┌16──────────────────────────────────────────────────┐ │┌⊖──┐ 2 112 88 41 20 10 26 62 98 101 2 101 10 112 88│ ││ │ │ │└───┘ │ └∊∊──────────────────────────────────────────────────┘ Here's a little table of English words; I make no claim of quality with regards to it, as it was haphazardly assembled: tptoe←'ah' 'lizard' 'nothing' 'collect' 'all' 'all' 'down' 'change' 'or' 'stay' 'to' 'and' 'trade' tptoe←tptoe,'thing' 'evil' 'tool' 'inside' 'nasty' 'person' 'yellow' 'have' 'fish' 'noise' 'arrival' tptoe←tptoe,'plant' 'ability' 'use' 'fruit' 'also' 'stone' 'paste' 'air' 'color' 'group' 'ear' 'if' tptoe←tptoe,'sleep' 'blue' 'head' 'cloth' 'cold' 'is' 'small' 'hair' 'book' 'red' 'truth' 'hand' tptoe←tptoe,'eye' 'hole' 'land' 'parent' 'money' 'woman' 'me' 'man' 'food' 'death' 'back' 'moo' tptoe←tptoe,'moon' 'game' 'many' 'spice' 'number' 'weird' 'path' 'bump' 'this' 'name' 'foot' 'oh' tptoe←tptoe,'eye' 'love' 'it' 'open' 'damage' 'work' 'stick' 'bread' 'give' 'of' 'heart' 'black' tptoe←tptoe,'end' 'bug' 'side' 'box' 'good' 'official toki pona book' 'like' 'heat' 'shell' 'what' tptoe←tptoe,'heaven' 'body' 'circle' 'new' 'you' 'face' 'symbol' 'knowledge' 'animal' 'big' 'sun' tptoe←tptoe,'floor' 'sweets' 'cause' 'but' 'moving' 'liquid' 'time' 'language' 'home' 'two' 'sex' tptoe←tptoe,'mouth' 'war' 'white' 'one' 'bird' 'strength' 'absence' 'want' Here's one thing I can do with that representation, along with this table: tptoe[1↓r] ┌15──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │┌7──────┐ ┌8───────┐ ┌4───┐ ┌2─┐ ┌4───┐ ┌2─┐ ┌3──┐ ┌4───┐ ┌3──┐ ┌9────────┐ ┌7──────┐ ┌9────────┐ ┌2─┐ ┌8───────┐ ┌4───┐│ ││nothing│ │language│ │good│ │is│ │have│ │to│ │use│ │many│ │you│ │knowledge│ │nothing│ │knowledge│ │to│ │language│ │good││ │└───────┘ └────────┘ └────┘ └──┘ └────┘ └──┘ └───┘ └────┘ └───┘ └─────────┘ └───────┘ └─────────┘ └──┘ └────────┘ └────┘│ └∊───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ This is clearly a poor translation, but it's better than nothing, and it's clear how making the machinery slightly more complex could add additional dimensions which would allow for one better. Isn't that neat?

>>28919 >Applicative State Transition Did you find a way to undo transitions the way you wanted?

>>29187 With its current design, all the MMC does is call a routine to ask questions, and each routine asks any questions until it has enough information to proceed; any default answers are provided by the caller, and new defaults for future commands are returned in the same way any answer is. All that's required to prevent undesirable changes is to change control flow to exit the routine without doing any of this; in Common Lisp, this is achieved with SIGNAL. The SIGNAL thrown is named REFUSE-TO-ANSWER, and is thrown by the questioning routines when invoked. A design not using such control flow, as may be required by other languages, involves an inversion of control, so that some infrastructure common to each routine is handed the next state, and can choose to skip over it or not. This is an obvious design for such things, but it was still interesting to see an Applicative State Transition system as described decades ago within it.

I've finished an article regarding an unusual programming style I find better than others: http://verisimilitudes.net/2022-01-31 Until the CSS be improved, the Gopher version is strictly better: gopher://verisimilitudes.net/12022-01-31 I've written a tiny Common Lisp program to exemplify this style. I named the functions AD-VERBUM-AB-NUMERO (to word from number) and AD-NUMERUM-AB-VERBO (to number from word), but I'll likely change these to AD-LITTERAS-AB-NVMERO (to letters from number) and AD-NVMERVM-AB-LITTERIS (to number from letters), as I figure this is more correct. In any case, how nice. I'll start, finish, and publish the Ada version soon, which should be much nicer. I'd be interested in learning what any of you think about this latest work.

>>29897 last night, i tried to read it. i thought "i'm just too high to understand this galaxy brain soykaf". today, i awake and caffeinate, and discover, "no, this dude is fuarrrking stupid or crazy". good luck lain.

>>29904 Tell me if it makes more sense over Gopher. Here's a proxy: https://gopher.floodgap.com/gopher/gw.lite?=verisimilitudes.net+70+31323032322d30312d3331 https://gopher.floodgap.com/gopher/gw.lite?=verisimilitudes.net+70+30323032322d30312d33312e72656164

>>28919 Stop following me and stop pushing that demonic sigil you fuarrrking russian weirdo

>>29907 I'm following no one, ain't Russian, and that sigil is a product of my mind alone, not demonic.

>>29897 So you first conceive a program as a table that maps all possible inputs to their outputs, and then, as long as the resulting table would be too big for practical use, simplify the table into smaller ones while complicating the logic with the rules for determining which table to index and how to combine their values. Sometimes I've tackled a problem by a combination of an algorithm and a small table of literal values, and every time I've found it ugly and wished to find a more general algorithm and get rid of the table. You suggest the opposite - to embrace the literal values and simplify the logic into mere indexing decisions. My gut feeling is that such an approach will lack the readability of either a full, explicit table or a pure algorithmic approach, but I'll try to give it a spin next time.

>>29897 >>29923 This remind me of prolog? ps i don't actually know anything about prolog. >Gopher FYI, Lynx has gopher support.

I wonder, how much mathematically inclijed are you OP? And how much do you think mathematical maturity is a necessity for programming?

>>29923 >So you first conceive a program as a table that maps all possible inputs to their outputs, and then, as long as the resulting table would be too big for practical use, simplify the table into smaller ones while complicating the logic with the rules for determining which table to index and how to combine their values. Yes, that's exactly right. For other problems, I may have conceived of the composition rule first; this is necessary for certain problems that aren't bounded. >Sometimes I've tackled a problem by a combination of an algorithm and a small table of literal values, and every time I've found it ugly and wished to find a more general algorithm and get rid of the table. The general algorithm could be useful for generating the table. >My gut feeling is that such an approach will lack the readability of either a full, explicit table or a pure algorithmic approach, but I'll try to give it a spin next time. Most code isn't understood by anyone but the author, if even him. Notice that this eliminates the need to consider a litany of edge cases and consult documentation, generally. With an explanation of what it does, a man could implement it himself and simply prove correctness by proving equality. >>29942 I focus mostly on discrete math and other things involved with computing. I don't consider myself particularly mathematically inclined. Programming well requires the ability to reason, think logically, and prove things; a great hacker will also have a sense of aesthetics that guides him. As a hacker, I'm most inclined to figure something could be or should be the case, follow that, and get into the proving stage last.

>>29897 What is the benefit of using tables so much?

>>29985 Rather than represent code as data, it's better to eliminate the code entirely, I've grown to think. Consider Lisp. Functions can be replaced as a program executes, and many other things are possible. A simple table, however, can easily mimic and overcome these advantages. A table can have its values changed as a program runs, but it can also enforce a structure more easily than arbitrary functions. It's also generally easier to change a value in a table than to modify and re-evaluate a function. With this in mind, why not use tables so much?

>>29989 Functions are nice because they are general. Anything can be considered a function including tables. >it can also enforce a structure more easily than arbitrary functions I agree about /arbitrary/ functions, but what is deficient about typed functions? They seem to provide complete flexibility to enforce any sort of structure (with a sufficiently strong type system). Could you tell me what precisely do u mean by "table"? any finite 2D array of data? some kind of mutable mapping? For example, how would implementing the unix tr program be different using tables from the procedural way it's written?

>>30002 >Functions are nice because they are general. Tables are also general. >Anything can be considered a function including tables. Yes, exactly. >I agree about /arbitrary/ functions, but what is deficient about typed functions? Lisp doesn't really support typed functions, and other languages don't allow the runtime changes Lisp does. >Could you tell me what precisely do u mean by "table"? any finite 2D array of data? some kind of mutable mapping? It's just a mapping. It could be considered two-dimensional, or not. It doesn't really matter, so long as it remains simple enough. >For example, how would implementing the unix tr program be different using tables from the procedural way it's written? That's not a good example for me. Give me a concrete and easily-stated problem to consider. Don't give me a problem involving UNIX.

>>30019 >other languages don't allow the runtime changes Lisp does So you're arguing that, given programming tools available now, most programs should currently be written using 'tables'? >It's just a mapping. >so long as it remains simple enough. So it's any "simple" mapping? How do you define simplicity? I would say addition is a simple mapping from two complex numbers to a third, but idk if u would count that as "table". >Give me a concrete and easily-stated problem to consider Consider the problem: a client wants to provide characters and a data stream. In return, they would like a copy of that data stream with every occurrence of the 1st character replaced with the second.

>>30030 >So you're arguing that, given programming tools available now, most programs should currently be written using 'tables'? At the very least, they could be written so. >How do you define simplicity? It maps some data to some other data. That's it. >I would say addition is a simple mapping from two complex numbers to a third, but idk if u would count that as "table". Addition is a table, but we can't have an infinite table. However, composition rules allow us to define a finite table and potentially use it to represent the infinite table. >In return, they would like a copy of that data stream with every occurrence of the 1st character replaced with the second. This is still just the UNIX garbage. I'll answer this, but then give me a better problem to consider. Map each possible character to itself or its replacement. If the domain be too large, such as would be the case with Unicode nonsense, use a sparse table representation wherein the character fragments map to another table or not, eventually ending in a table mapping each remaining character to itself or its replacement. I'm being vague, but this is simple to consider. I'll use hextet characters as an example: Map the first octet to a table for the second octet or not; map the second octet to its replacement or itself.

I present to your consideration Teliva: https://fosdem.org/2022/schedule/event/lastmilesandboxing/ https://github.com/akkartik/teliva Now, we all here can find a number of things that are wrong with this software as it is, but it is merely a proof of concept, so let us consider the concept rather than its toy implementation. It combines two ideas, neither of which are new on their own: one, that all software that a user uses should come in source form, ready to be modified on the spot; two, that programs should be sandboxed and granted permissions only explicitly by the user. Underlying these, we find two claims: - conventional software freedom is not enough to keep software accountable to its users (build requirements, for example, can make modification prohibitively difficult for most) - users can't be expected to trust all the software they use, even if it is Free (complex software offers plenty of room to hide nasty behavior) I think these ideas are not yet mainstream among the Free Software community, yet they should be. The 'Seven Laws of Sane Personal Computing' (linked at >>29038) contain them, but Teliva makes them more specific and more directly tied to users' digital rights. They're so specific that you can't help come up with possible implementations as you read them, but what difficulties might lie in wait? All software in source form, either interpreted or compiled quickly and transparently? It's been done before, in environments built around a single language and implementation. Will it not result in a closed ecosystem that's incompatible with any software from outside it? Everything sandboxed, no permissions by default? Smartphone OSs do this, and we know how that works out: overly vague permissions that don't inform the user at all, and the implicit message that accepting them is the only thing to do. The user only feels more powerless after explicitly giving up a control he didn't have a chance to understand. Allowing the program to run even if permissions are denied (e.g. by pointing it to a mock filesystem or network interface) is an improvement, as it teaches the user that there really is a choice. But can you interactively ask for fine-grained permissions without overwhelming the user into yielding control?

>>30239 >akkartik I once considered contacting him, to show my work, but decided it were beneath me. I'm not downloading the twenty-minute video, and see no transcript at a glance to read instead. Were I to describe him with one adjective, it would be graphomaniacal; just look at this part of his mu: https://raw.githubusercontent.com/akkartik/mu/main/123slice.subx Many files are just like this. This is More comprehensible and rewrite-friendly software? Compare this insanity to my beautiful MMC. I've a system for the lowest-level programming, but still elevate it with simple mechanisms, and am still refining it. This mu is worse than an assembler language, and utterly incomprehensible. I move away from text as a medium, away from all names, but he certainly doesn't. This Teliva idea is clearly worse than Smalltalk and similar such systems. I prefer the Seven Laws of Sane Personal Computing, not a knockoff. >It's been done before, in environments built around a single language and implementation. Will it not result in a closed ecosystem that's incompatible with any software from outside it? That's exactly what this Teliva is. This is quoted without comment: >Teliva's codebase also includes forks of the following reputable brands I believe a better way to secure software is to express software divorced from power entirely. A program can be expressed in a way that avoids all issues by construction; as Loper-OS is being referenced again, see this and my comments: http://www.loper-os.org/?p=288#comment-20009

ITT: Blah blah blah, unenlightened rubbish. Seek ye The Aquatic Language or Angelic Language - Language of the Birds... English itself is egyptian and sumerian and etc in form. Each glyph of a word in English writing is hieroglyphic. Wazz Dere?! Wuz There? ... Wizzerd! Lingu-age iz Mal-abel, matee. Speak liek a Pi-Rate furrst, Before ye try t` cut-a-lass wif a gut-glass, Cutlass. An Praise Cheeses! Ye know not wot ye due. You're caught in the existent form an mode of written word... But thems that sound the same, arrr! A Pirate really do gots a wooden pen-is mightier that thiSword! Spun about like a Cum-pass, circle-jerk like at the rate 'o Pi! And let me level with you mate - you're going the wrong way trying to codify for mundane machines yer systems of meanin.... Already there exists Analog Gods!

>>30249 >Language of the Birds Thoth about this a bit. [points to Great Destroyer] Ammut! [points to the castle walls] Amoat! [points to own bared teeth] A-mout! I'm out.

I've finished a tiny little set of programs relevant to Elision; it has WWW and UDP interfaces: gopher://verisimilitudes.net/12022-06-13 http://verisimilitudes.net/2022-06-13 This is my reflection on it: gopher://verisimilitudes.net/02022-06-17 http://verisimilitudes.net/2022-06-17 It's some progress, at the very least.

I've made some progress on my language modelling work, and will release some of it soon, but my problem is that it still amounts to a toy. Much more work than was anticipated is needed for it to move beyond what feels to be a toy. One thing that's obvious is that I should scale down the early work and use the tool on poetry, since that will be small and simple enough for demonstration and significant enough for real progress to be shown, but even that will feel unimpressive without more work upfront. I'd be best off with funding for my work and at least one helper, but that won't come, and it also occurred to me that pursuing someone else's ideas could do for me some good. Unfortunately, every time I try to contact some research center, I never receive any replies, so I can't expect to be paid for helping to breathe life into someone else's vision either. Since I made this thread for unique software and insidious optimizations, I believe Pest to be worthy of mention: http://pestnet.io I already have most of the needed pieces scattered about my workspace, and believe I can approach the problem in a better way than what I've seen of the other implementations. It's sufficiently simple and bone-like that I expect to use Ada, but my design will allow for Lisp, Emacs, or anything else to interface with that Ada well enough. I'm not particularly interested in Pest beyond using it to communicate with a select few, and it's not the manner of system I would ever design, but it still has something like a beauty about itself, and even could be useful as the transport mechanism of other works; it should be a suitable reprieve from my usual work.

I finished all of the libraries I need, but have yet to finish my Pest implementation in Ada. I'll see how long it takes me before I move on to other work.

>>30249 >>30250 I thank God that I was born a high-functioning autistic and not this kind.

>>33804 I still haven't finished this yet. I've learned so much about Ada in the past few years, and every diversion I took gave me valuable knowledge I've used in this, but the implementation is still sitting incomplete in my working directory. Not much more effort would be needed to get it in a tenuously working state. I'm bored, and hardly even post here anymore. I can no longer have interesting discussions here, perhaps. Years of conversations get dozens of comments before dying, and the faster websites are no better. I'll likely never have the camaraderie those men in the laboratories had.

>>40356 Get used to it, the west is dying of decadence and anything that's not part of the global hedonism has to be done by hermits.