W dokumencie RFC 3492 — opisującym IDNA “punycode” — do wyznaczania progów dla każdej cyfry zapisu liczby naturalnej o zmiennej podstawie, poniżej których wartości w danej cyfrze są nieużywane po to, by użycie takiej wartości cyfry oznaczało koniec liczby zapisanej w ciągu bez separatorów, ale oczywiście, by taka wartość cyfry nie była ignorowana, lecz wliczana jako cyfra o najbardziej znaczącej wielokrotności w cyfrowym o zmiennej podstawie zapisie tej liczby — zamiast wyznaczonej sekwencji progów (które mogłyby być bez tego jedynkami, dla zer oznaczających koniec) zastosowano funkcję prognozowania każdego kolejnego progu i obliczania na jego podstawie wielokrotności pozycji cyfry, która jest funkcją kolizyjną (zmierzającą do jednej formy ciągu wynikowego) szarpaną w górę wartościami obliczanymi z niejawnych współczynników względnych oraz z jawnych stałych modyfikujących wartości drobne. To powoduje, że jakiekolwiek wnioski z pierwszej połowy tego dokumentu — o celu zastosowania i właściwościach zapisu liczbowego o zmiennej podstawie (zmiennej wielokrotności kolejnej) nie są prawdziwe dla całej funkcji “punycode”, która kosztem tracenia kompresji wszystkich cyfr zapisywanej liczby oprócz ostatniej szuka takiego progu dla ostatniej cyfry, by dało się rozpoznać cyfrę końcową (o wartości poniżej progu), a rezultat (zapis “punycode”) jest o wiele mniej optymalny niż przy zastosowaniu innego algorytmu, bez wymuszania takiego skomplikowania funkcji analogowej na cyfrowości.
Jeśli wydarzenia takie jak wiadome trzęsienie ziemi na Haiti niszczące stolicę i trzęsienie ziemi w pobliżu Japoni niszczące falą tsunami elektrownię atomową rzeczywiście zaistniały i nie były świadomie zainicjowane przez człowieka/ludzi ukierunkowanym, bezpośrednim działaniem tuż przed nimi — to wtedy istnieje materialna warstwa nośna odbioru informacji przez człowieka, a być może przez organizmy żywe. Informacji o zmianach lokalnych jakiegoś pola naprężeń, może grawitacyjnych, może lokalizacji mas. Jeśli ewentualnie te wydarzenia zaistniały, lecz zostały bezpośrednio zainicjowane przez człowieka/ludzi (czyli ewentualnie niezgodnie z publiczną wiedzą), to wtedy można raczej przypuszczać, że to organizmy żywe emitują w nieznany sposób informacje na tej warstwie. Jakkolwiek – obliczona dla tych trzęsień ziemi (tak jak dla wszystkich jest obliczana) siła naprężenia w skorupie ziemskiej mającego być naturalnym bezpośrednim źródłem trzęsienia ziemi na powierzchni raczej przekracza możliwości człowieka: by dostarczył taką energię albo przesunął strukturę materii i uwolnił przepływ zgromadzonej naturalnie energii — na takiej głębokości w skorupie ziemskiej.
Tak jak język programowania C w formie już używalnej, niekoniecznie mającej standard, był pewnego rodzaju zmianą sposobu programowania, ponieważ jego zapis składniowy był dla człowieka swobodny a czytelny względem stosowanych wtedy języków typu ‘functional’, które miały być najbardziej czytelne, a język C umożliwił stosowanie instrukcji wykonawczych maszyny, które są w tamtych językach niedostępne, ponieważ języki typu ‘functional’ opierają się na obliczalności matematycznej (definiują implementacje funkcji matematycznych), i język C określił pewien (nienazwany) czytelny rodzaj proceduralności maszynowej (a nie matematycznej) w zapisie programu — tak język Coux w jego obecnej postaci implementowalnej określa w strukturze tekstu pojedynczego źródłowego pliku programu pewien rodzaj 〈programowania nieliniowego〉, które umożliwia ciągłą strukturalizację ‹modułu› OUX (zawartego skończenie w dowolnej liczbie plików źródłowych), podczas gdy środowisko przepływu wykonania — niezależnie od nieliniowego zapisu tekstu programu — także ma określoną strukturę użytkową w postaci adaptowanych z systemu lub podsystemu ‹raportów› oraz zintegrowanej wewnętrznie wielozadaniowości OUX, a nie jednowątkowe lub wielowątkowe proceduralne wykonywanie się programu C.
Język C na początku był przełomem z bezpośrednio wykonującej się uniwersalności, później był uzupełniany i rozgałęziony na C++, lecz spośród tych uzupełnień tylko niewiele ułatwia implementację Coux na bazie C, a wcale nie są wymagane, natomiast C++ jest sprzeczny, mimo że można by również na jego bazie utworzyć ·nieoptymalną· implementację Coux. Dlatego w tym momencie w sensie programowania w nowoczesnej koncepcji OUX należy potraktować C++ jako zdegenerowaną gałąź programowania, a C jako przestarzały standard, o prymitywnej względem obecnej koncepcji programowania; standardy najnowszych wersji tych języków. Do programowania w Coux potrzeba względem C:
- ⁃ Odrzucić bibliotekę C i typy standardowe, co nie wyklucza ich użycia opakowanego.
- ⁃ W obszarze globalnym pliku źródłowego stosować ‹obiektowość ogólną› zapisywaną w postaci nazw symboli — zamiast dowolnych proceduralnych.
- ⁃ Podczas programowania projektować strukturę programu względem ‹atomowego› przepływu wykonania.
Na przykład C nie pozwala na tzw. “closures” (przenaszalne obiektowo ‚procedury w procedurze’), ale “closures” są sprzeczne z Coux, ponieważ są elementem ‹obiektowości instancyjnej› w obszarze ‘functional’ języków obiektowych. W Coux zamiast “closures” należy stosować procedury pochodne od wymagającej ich w przestrzeni globalnej umieszczone w strukturze pliku źródłowego ‹programowania nieliniowego› i umieszczone (z własną nazwą) w ‹obiektowości ogólnej›, a wtedy takie procedury na zasadzie ‹obiektowości ogólnej› podpadają pod ciągłą strukturalizację programu, tworzenie niepowtarzalnych funkcjonalności uniwersalnych.
Przez wiele lat nie wiedziałem, dlaczego nowe, efemeryczne paski przewijania w oknach, które zaczęły się pojawiać pierwotnie na stronach ‘www’ zawierających specjalne wpisy styli CSS, a globalnie – później, w podsystemach i pseudosystemach występujących teraz powszechnie na wierzchu systemów rzeczywistych — tworzą wrażenie czegoś morderczo zimnego i przez to odrażającego. Dlatego, że wyglądają, jakby miały odpaść z ekranu, i — mimo tego — jeszcze się poruszają.
Dane mają wiedzieć (przez funkcje “abstract” obiektów), gdzie mają być (przetwarzane) — dlatego, że są ustawione na określoną wartość (definicja obiektu bezklasowego lub pochodnego). Zamiast tego, że wartość danych jest w tym, gdzie ma być, użyta odpowiednio do oczekiwania rodzaju danych.
Czyli jak wygląda obiektowość w C++, Javascript i innych, a zaczęło się od ogólnych języków obiektowych, koncepcji, takich jak Self (?) i Simula (?), które wprowadziły C++‐owy “this” (obiekt bieżący oderwanej procedury).
To jest tylko wzorzec użycia tych języków programowania stosowany powszechnie i wspierany przez definicję poszczególnego języka programowania. Dowód formalny błędu założeń C++ powstał dużo wcześniej i wyeliminował konieczność jakiegokolwiek dalszego uzasadniania funkcjonowania programów napisanych w C++. Więc jest to tylko spostrzeżenie sposobu programowania, który nie musi być stosowany w tych językach programowania — nie mających przecież ustalonych reguł, mimo że w C++ standard języka wbudował formalnie elementy składni dla tego wzorca programowania, a na przykład Java umożliwia używanie tego wzorca w sposób strukturalny tworzonych definicji obiektów (czyli tworzonych ‘class’).
Podczas projektowania implementacji programu, który ma się integrować z systemem, z którego korzysta (biblioteki współdzielone) lub na którym jest oparty (pasująca struktura API używana bezpośrednio) — są dwa otwarte na możliwości, syntetyczne rodzaje realizacji fragmentu programu wykonującego coś ze zbiorem danych:
- • Uruchomienie jakiegoś wymaganego algorytmu przetwarzającego.
- • Wykorzystanie danych cząstkowych, które pojawiają się w takim algorytmie — do następnych czynności programu.
Użycie jakichkolwiek danych struktury — bieżącej lub przyszłej — pojawiających się w algorytmie wymaga zmiany algorytmu, który jest realizowany z użyciem gotowych fragmentów struktury programu obecnych z integracji z systemem, a także w systemie. Natomiast konieczność projektowania w tych otwartych rodzajach realizacji powstaje stąd, że dane same siebie nie wykonują równolegle tak, jak każdy byt materialny z osobna, jakkolwiek rzeczywiste byty materialne (czyli posiadające rzeczywistą strukturę budowy) są niezmienne a niedoskonałe.
W OUX [1.5], która to wersja jest wewnętrznym etapem rozwoju technologii OUX (jakkolwiek samodzielnie w pełni funkcjonalnym w dotychczasowych możliwościach) — powstała właściwość ·rzeczywiście· „nieskończonego czasu wykonywania się”. Jest to właściwość strukturalna technologii, która była od początku w projekcie, lecz nie została wtedy nazwana przy braku słów opisu czegoś, co jeszcze nie było zaimplementowane.
Trzeba pamiętać, że ‹zadania› zdefiniowane w technologii OUX są zadaniami funkcjonalnymi, to nie są w żadnym rozumieniu zadania równoległościowe (np. do obliczeń równoległych) znane z definicji tzw. “threads” (wątków) i użycia tamtej koncepcji w dowolnym systemie operacyjnym. Dla programistów, którzy na przykład pochodzą z użycia technologii C++, mógłbym powiedzieć, że ‹zadania› technologii OUX (mające źródło słowotwórcze z tzw. “task” technologii programowania procesorów Pentium) są jak pierwotne, ogólnego rodzaju ‘class’ w technologii C++, gdyby takie ‘class’ były wprost (a nie z nadania cech) procedurami “main” w technologii C. (Gdyby każdy element i właściwość technologii C++ nie wzbudzały we mnie obrzydzenia waszymi niecnymi uczynkami… :-> )
Więc wymieniona na początku ta właściwość technologii OUX nie jest określeniem tego, że program OUX wykona się gwarantowanie, ponieważ każdy programista definiuje ‹zadania›, dając względem nich własne gwarancje; tak samo jak w programach OUX autora samej technologii te gwarancje są wspólne z technologią. Ta właściwość jest natomiast określeniem tego, że ‹zadania› (funkcjonalne) mogą być wyrzucane i tworzone w trakcie wykonywania się programu, ponieważ te funkcje (‹obiektowości ogólnej›) ‹zadań› już przynależą do pełnej integralności wykonywania się programu w technologii OUX. I właśnie to widać wprost na prezentacji filmowej programu testowego ‟OUX [1.5] sample”: każde otwarcie pierwszego okna i zamknięcie (tutaj automatyczne) ostatniego jest nie pośrednio utworzeniem i wyrzuceniem ‹zadań› ‚systemowych’ znajdujących się w tym programie, a służących do obsługi podsystemu okien znajdującego się w systemie operacyjnym, w którym ten program jest uruchomiony. To tworzenie i wyrzucanie ‹zadań› jest dokonywane wprost poleceniem w tekście programu i w sposób ogólny, nie przystosowany specjalnie do jednego zastosowania ‹zadania›. Czyli można powiedzieć, że każde ‹zadanie› w technologii OUX może i powinno być ‘restartowane’ na takiej samej zasadzie w efekcie jakby każde z osobna było samodzielnym systemem operacyjnym realizującym zdefiniowaną nim funkcję; oczywiście bez gubienia zasobów systemowych i pozostawiania niezdefiniowanego stanu systemu nie przypadkowo. Ta właściwość technologii OUX oznacza, że przy zgodnym z tą technologią programowaniu programu OUX program bez czynienia przez programistę szczególnych wysiłków w tym celu — może realizować jakieś zadanie zewnętrzne, np. wyświetlanie ‘interfejsu’ graficznego człowiekowi lub komunikacja sieciowa, to zadanie może zostać uszkodzone na zewnątrz z jakiegokolwiek nieznanego powodu, które to uszkodzenie jest zauważalne w postaci wyrzucenia zasobu zewnętrznego przez podsystem zewnętrzny (czyli tutaj – zniknięcie okna), zablokowania zasobu zewnętrznego w podsystemie zewnętrznym (czyli tutaj – zaprzestanie odświeżania jego obrazu, obsługi zmiany ramki: nakładanie się innych obrazów na okno, ‚nieresponsywność’ na polecenia użytkownika) lub uszkodzenia kooperacji ‹kształtek› wyświetlania w oknie (czyli tutaj – niemożliwość zmiany ich wartości przez użytkownika, problemy z ‚focusem’ lub ‚pointerem’) — może realizować to zadanie zewnętrzne i w każdej chwili utworzyć nowe bez utraty danych, które były do czasu uszkodzenia zadania zewnętrznego.
W wyniku dotychczasowej historii programowania w kierunku OUX pojawiła się nowa konieczność i jej realizacja w tego rodzaju programowaniu: ze względu na bezzwłoczny przepływ wykonania (tzn. bez “sleep” lub “idle” priorytetowego) programu OUX system operacyjny lub jego podsystem ukazuje nieraz swoje błędy wewnętrznej niegotowości, która wynika z proceduralnego podawania programowi OUX (tak jak każdemu innemu by) jako wyniku jakiejś procedury sukcesu operacji nakazanej w (przestarzałej) proceduralnej technologii programowania, dla której te systemy operacyjne zostały wytworzone. Dlatego oprócz definiowania ‹raportów› projektowanej struktury ‹atomowego› przepływu wykonania programu OUX trzeba definiować pochodne od bieżącej struktury programu — ‹raporty› zwrotne, które oczekują na system operacyjny lub jego podsystem do zakończenia bieżącej podczynności na rzecz tego programu.
Menedżer nie zarządza obiektami identycznymi, ale obiektami otrzymanymi — na zasadzie uchwytów cech żądanych przez użytkownika. Instancja jest obrazem separatystycznym z wzorca definicji klasy, dla którego to obrazu rozgałęzia się już zauważoną rzeczywistość w oczekiwaniu na ponowne zauważenie tego samego przez każdą instancję osobno, obliczając tak samo. Jest to ostateczne wykluczenie użycia instancji w językach programowania przez ukazanie, że instancjacja jest wirtualizacją w dodatku połączoną z dezintegracją przepływu wykonania i zasobów — dla mnożenia obrazu, bez stosowania jakości. Co ostatecznie eliminuje użycie Javy, jej pochodnych zgodnych, C++ w programowaniu obiektowym, rozszerzeń obiektowości instancyjnej pozostałych języków programowania.
Uproszczony obraz bytu (schemat) może być prezentowany w zgodzie z prawdą tylko wtedy, gdy jest podany obserwator względem tego bytu (m.in. kierunek) oraz stopień (lub właściwie – na konkretnej drodze patrzenia, typie patrzenia, ale nie rodzaj jako taki) doprecyzowania (analogia konturowa do przybliżania fotograficznego w czasie oglądania bytu, bez zmiany kadru w detal). Te informacje osadzenia mają być ujęte w formie opisu pozycji własnej obserwatora patrzącego na ograniczony fragment przestrzeni w sposób dynamiczny; nowoczesny sposób opisu prostego lokalizacji fotografii względem dwóch obiektów, by nie precyzować bezwględnie stanu przestrzeni przeszłości.