Zakładając, że czytający ten tekst zna jakiś język programowania, w którym coś potrafi napisać, cokolwiek by to robiło, ale jest oprogramowaniem, a nigdy nie zna się po prostu języka programowania, lecz technologię programowania, w której używa się tego języka programowania, lecz tego nie zauważa, bo środowisko programowania już jest, nieznane, używane, nazywane językiem programowania, który jest tylko matematyczno‐symbolicznym zestawem reguł, częścią technologii nałożoną na możliwości jej wewnętrznego działania — albo zakładając, że czytający ten tekst nie ma pojęcia o żadnym języku programowania, lecz na pewno używa rzeczy, które realizują zapisane w nich programy, i też uczestniczy w tym, co się dzieje, w interakcji z maszynami, których machanizm jest ukryty a rozumiany, mimo że nie potrafi go rozumieć w jego programie rzeczywistym, wewnętrznym — ukazuję tutaj zagadnienie, które w międzynarodowym języku informatycznym jest nazywane ‘debugowaniem’ oprogramowania (co po polsku znaczy „usuwanie ukrytych błędów”) z różnymi zamianami tego słowa na inne, alternatywne eufemizmy, by być może ukrywać coś wstydliwego, co ukazuje własne błędy, a nikt nie chce przyznawać publicznie, że naprawia swoje pomyłki, że były jakieś pomyłki, są lub mogą być. Metody ‘debugowania’ są mnogie, a są nim właśnie tzw. ‘traceʼowanie’ (‘tracing’ czyli historia pojawień się lub niepojawień wykonywania w którychś zaznaczonych miejscach procedur programu), ostatnio bardzo popularne jako ‚certyfikaty’ poprawności oprogramowania – tzw. ‘case tests’ (testy przypadków czyli pojedynczych użyć wykonanych poprawnie), listy zgłaszanych przez użytkowników nieoczekiwanych lub niechcianych zachowań oprogramowania spostrzeganego jako zachowania maszyn nim oprogramowanych, i cokolwiek innego by programiści wymyślili, co miałoby służyć zmianom tego, jak oprogramowanie jest zapisane w strukturze językami programowania.
Odpowiednio do rozumienia oprogramowania przez daną osobę — zagadnienie ‘debugowania’ — jakkolwiek właściwe bądź nie w tworzeniu oprogramowania, ale obecne w cudzych technologiach wytwarzania — zawiera takie aspekty jak:
- • Czy oprogramowanie może być doskonałe? Kiedykolwiek – z ‘debugowaniem’ lub bez.
- • Czy ‘debugowanie’ rzeczywiście pozwala usuwać błędy oprogramowania? Czy ‘debugowanie’ w ogóle te błędy ukazuje programiście? A trzeba pamiętać, że ‘debugowanie’ w tej definicji to nie tylko to, co programista sprawdza sam, ale też to, co inni ludzie oceniają podczas użytkowania, więc jest to spostrzeganie umysłów ludzi ze społeczności.
- • Czy programista tak naprawdę rozumie rzeczywistość działania maszyny, którą oprogramowywuje w języku programowania?
- • Czy użytkownik rozumie rzeczywistość funkcji maszyny oprogramowanej, której używa? Rzeczywistość jej działania w interakcji własnej z danymi funkcjami.
Aspekty te nie mogą być rozumiane oddzielnie, rozważane odrębnie, mimo że w tym momencie mogą być niepojmowalne jakoby problemy rozważań teoretycznych. Te wydawało by się problemy pochodzą od jednego założenia i są zrozumiałe i rozwiązywalne całkowicie, jeśli się tego założenia wyzbyć w programowaniu lub użytkowaniu maszyn, ale nim o nim napiszę później, to zobaczmy, skąd każdy z tych problemów powstał bezpośrednio:
- • Problem rzeczywistości zachodzącej a programu tylko wykonującego coś w tej rzeczywistości lokalnie.
- • Problem możliwości sprawdzania przebiegu rzeczywistości tak, jak się chce.
- • Problem rzeczywistych podstaw stosowanej technologii programowania.
- • Problem właściwego inicjowania i zatrzymywania rzeczywistych przemian funkcjami maszyn.
Jeżeli uważa się, że program powinien działać tak, jak zamierzono, dla czegoś, a nie będąc w czymś, czyli jeśli program nie mogąc być globalnie wszystkim, jest tworzony tak, by działał dla wszystkiego, to z założenia nie może być doskonały — musi być aspektowy, ponieważ coś rozpozna z tego bytu, a coś z innego, więc będzie działał (o ile wogóle właściwie) tylko w określonym, ustalonym ułożeniu rzeczywistości, co do której przecież nie ma gwarancji, że będzie takie samo zawsze. Natomiast jeśli program jest tworzony tak, by działał we wszystkim, co jest w danej maszynie, a nie po pierwsze dla wszystkiego, co jest na zewnątrz, to wtedy takie oprogramowanie mogłoby być doskonałe w tym, czym jest, we własnym bycie przemian, wykonując się na doskonałych bytach własnej budowy.
Tak samo zrozumiałe jest próbowanie powtarzania przebiegu rzeczywistości na podstawie tego, co jest rozpoznawane częściowo z różnych bytów: może wydawać się wtedy, że rzeczywistość się powtarza, ponieważ obrazy się powtarzają przy jakichś działaniach programu, ale to nie jest rzeczywistością, choćby od początku zawsze się powtarzały tak samo. Właściwie to wtedy wydaje się, że rzeczywistość się powtarza ·zgodnie z działaniem programu·, że taki program swoim działaniem o niej decyduje, a nie to, że rzeczywistość powtarza się w ogóle, bo obrazy się powtarzają, lecz niesposób ich zrozumieć nawet poza maszyną, nie znając rzeczywistości ich źródeł, i niesposób zrozumieć, co się powtarza przez to, że te obrazy się powtarzają. A podstawowe założenie własne o rzeczywistości tutaj jest takie, że można ją zatrzymać, by sobie posprawdzać jej fragmenty globalne, a następnie wznowić bieg rzeczywistości. Przecież gdyby tak było, to każdy by miał własny świat globalny, to jakakolwiek informacja byłaby bez sensu rzeczywistego, a to jest sprzeczne, bo właśnie to jest realizowalne nieprawdziwie tylko przez powyrywanie ze świata rzeczywistego jego fragmentów, by się wydawało. Więc zatrzymawszy program podczas ‘debugowania’, nie wznawia się go w tej samej rzeczywistości, która będzie, jeśli by się go nie zatrzymało.
Środowisko programowania, w którym używa się języka programowania, tworząc struktury w danej technologii programowania, może zawierać — i z mojej wiedzy napewno popularne technologie programowania zawierają — algorytmy, które nie realizują rzeczywistych funkcji maszyny, na której to środowisko programowania jest, lecz realizują podstawianie programiście, dla jego uproszczonego rozumienia przebiegu rzeczywistości w tym środowisku, właściwości, na które liczy programista. Tymi właściwościami wymuszanymi na rzeczywistości dla zaistnienia pewnego przebiegu mogą oczywiście być tzw. ‛ograniczenia środowiska programowania’, które są zauważane po pewnym czasie programowania w jakiejś technologii, ale to są nierzeczywiste właściwości dalszego rzędu, natomiast pierwszego rzędu właściwościami symulacji rzeczywistości są fundamenty środowiska programowania danej technologii. Tymi fałszywymi fundamentami, które ma widzieć i do których ma stosować się programista, są takie elementy programowania jak na przykład tzw. ‛sygnały’ wymagające procedur obsługi w technologiach tzw. ‛programowania zdarzeniowego’, gdzie właśnie w tych procedurach obsługi dokonuje się interpretacji fragmentów ‚zatrzymanej’ (w złudzeniu) rzeczywistości globalnej, albo tzw. ‛obiekty’ w technologiach tzw. ‛programowania obiektowego’, które zawierają w sobie niezachodzące z innymi obiektami fragmenty obrazu rzeczywistości, który za chwilę zmienia się, a program tak napisany zawiera już nie wiadomo ile zależności od jakichś podstawowych klas tych obiektów, które opisywały w języku programowania jakiś wyrwany fragment obrazu do użycia globalnego w programie jako funkcjonalność rzeczywistości, a tak naprawdę wirtualność (czyli utrzymywanie obrazu rzeczywistości dla) programu w tzw. ‛programowaniu obiektowym’. W rzeczywistości zależność od środowiska programowania to nie jest zależność od twórcy tego środowiska, który mógłby warunkować nierzeczywiście jego swobodne użycie, ale jest to zależność od nierzeczywistego oprogramowania będącego tym środowiskiem programowania, które wytwarza nierzeczywiste środowisko do tworzenia nierzeczywistego oprogramowania, i to oprogramowanie przestanie działać nienaprawialnie, gdy tylko zmieni się opisywany wcześniej obraz rzeczywistości w taki sposób, że twórca środowiska programowania nie będzie potrafił się dostosować do rzeczywistości w wymuszanych dotychczas przez niego regułach programowania.
Natomiast użytkownik maszyny oprogramowanej nie musi wiedzieć, w jaki sposób jest szczegółowo wykonywana każda pojedyncza funkcjonalność części maszyny, ale tylko wtedy, gdy ta realizacja nie przekracza granic bytu części, ponieważ zna przemianę własną tej części i jej funkcjonalność do zastosowania. Jakkolwiek jaki użytkownik i która maszyna? Przecież większość użytkowników chce maszyn nie po to, by mieć możliwość coś robić przez ich zastosowanie jako rozszerzenie narzędzi własnego ciała, ale po to, by maszyna sama robiła bezmyślnie to, do czego służy. Oczywiście, że maszyny robią wszystko bez niepotrzebnej uwagi człowieka, maszyny automatyczne, ale tylko wtedy, gdy człowiek jest gotowy w każdej chwili dokonać korekty działania maszyny w jej oprogramowaniu, gdy obszar bytowy jej funkcjonowania miałby się zmienić lub zaistniało uszkodzenie, a robi to na podstawie pełnej wiedzy o rzeczywistości, podczas gdy maszyna realizuje tylko pewne programy wymagające czasu realizacji dłuższego niż ich rozumienie, zaprojektowanie. I przecież maszyny nie mogą ze względu na rzeczywistość materii być zbudowane tak, by każda ich część nie przekraczała granic własnego bytu, lecz mogą tylko być usilnie tak projektowane, ponieważ byty, z których składają się te części maszyn, nie są doskonałe, nie zawierają doskonałych struktur przełączania bytów, lecz opierają swe działanie na tzw. ‛energii’, która wynika z wybijania bytów ze struktur i wpadania do struktur, mimo że ta energia jest jedynie wskaźnikiem (o ile dostępnym do odczytu, więc teoretycznie dostępnym) uszkodzeń wewnętrznych struktury części maszyny; opierają swe działanie m.in. na utrzymywaniu się mas bytów bez struktury.
Stąd tzw. ‘debugowanie’ oprogramowania to jest zaawansowane wytwarzanie złudzeń posiadania właściwego oprogramowania, gdy nie ujmuje się całości tego oprogramowania we własnym umyśle. Ponieważ program składa się z nałożonych na siebie algorytmów integralnie wykonujących coś podczas przebywania pojedynczej drogi i trzeba wiedzieć, co i dlaczego w całości to ma robić i robi, co się dzieje w danym momencie, a niemożliwa jest obserwacja kolejności, lecz trzeba w umyśle potrafić odtworzyć całą rzeczywistość bytu i struktury maszyny, w której ma wykonywać się projektowane i implementowane oprogramowanie — tak, by mimo dowolności w kolejności wykonywania się bloków programu zawsze rzeczywista funkcjonalność części maszyny była zachowana i najefektywniejsza dla realizowanego celu całościowego. Wbrew pozornym ograniczeniom pasywnym w powszechnych technologiach programowania — przekraczając ich fundamenty, ale bez opierania się na niedopowiedzeniach technologii, czyli dokonując w umyśle oprócz programowania zwykłego jeszcze konwersji środowiska na programowanie właściwe, da się w tych technologiach o fałszywych fundamentach programować ograniczone funkcjonalności prostych maszyn, co sprawdziłem w wielu językach programowania tzw. ‛ogólnego’, które jednak nie są językami uniwersalnymi lub swobodnego programowania, oraz w językach specyficznych do aplikacji lub przenośnych pomiędzy aplikacjami, osadzanych. Jednak nie należy się spodziewać, że twórcy tych środowisk programowania nie zechcą blokować aktywnym ograniczaniem możliwości takiego programowania, z jakiegokolwiek powodu świadomego bądź pośrednio świadomego (jeśli wydawałoby się dla czegoś innego).
Programowanie rzeczywiste, a w szczególności w technologii OUX, oczywiście nie jest tożsame z bezbłędnością, jakkolwiek występujące w nim błędy są całkiem innego rodzaju niż te w technologiach nierzeczywistych. Generalnie są to błędy dwóch rodzajów: ‣ pomyłki co do szczegółów rzeczywistości skutkujące błędnym jej odwzorowaniem, co powoduje natychmiast błędne działanie zintegrowanego programu jako całości przy użyciu jego funkcji korzystającej z tego odwzorowania, ale jest to wyszukiwalne w tekście programu, ‣ obszary niewykonania lub opuszczone fragmenty przejścia pomiędzy podwykonaniami, czyli gdy program zachowuje swój byt przemiany, lecz nie zostało zaimplementowane wykonanie czegoś podczas drogi tej przemiany albo jeszcze nie zostało zaimplementowane i dodatkowo nie zostało w ogóle uwzględnione już uruchomienie programu, więc nie zostało zaimplementowane następstwo tego co przed pustym fragmentem implementacji z tym co po nim, ale jest zachowany ogólny cykl przemiany, z którego rozpoczęto projektowanie oprogramowania, mimo błędu w tej procedurze implementacji. I oczywiście w programowaniu rzeczywistym algorytmy uwzględniają to, że rzeczywistość nie jest zatrzymana podczas przetwarzania wstępnie jej obrazów bytów, a w szczególności rozumianych przez program sygnałów bytowych, lecz używają tego samego źródła bieżącego w czasie wykonywania się programu, który jest możliwy w rzeczywistości, mimo że ta rzeczywistość zawsze jest szybsza w istnieniu, lecz ma być strukturalnie przygotowana, przewidywana w oczekiwaniu. I specyficzną właściwością programowania rzeczywistego jest to, że nie posiadając powyższych dwóch błędów zawsze przeszłoby ono pozytywnie wszystkie testy przeznaczone dla oprogramowania nierzeczywistego, a wcale nie oznaczałoby to, że jest ono napisane właściwie dla rzeczywistego celu: z powodu tego, że do poziomu, gdzie sprawdza się błędy składniowe języka programowania, przesunięte jest w tym programowaniu też to, co sprawdza się w programowaniu nierzeczywistym z zewnątrz, można napisać cokolwiek destrukcyjnego w rzeczywistości, mimo że nie wystąpi żaden błąd wykonania, z którymi mają ciągle problemy programiści w programowaniu nierzeczywistym, ale to co robi program jest jawnie w tekście jego zapisu.