Nowość radykalna

"Far be from us, Sire, the dangerous novelty of thinking."

W szkole średniej na kierunku "język polski - specjalizacja systemy komputerowe" (pisanie wypracowań na polski zabierało z 3-4 razy więcej czasu niż praca z jakimikolwiek komputerami - z perspektywy czasu trudno mi ocenić czy to dobrze czy źle) często musieliśmy analizować słownie lub pisemnie teksty dawnych twórców.

W programowaniu także mamy "dawnych twórców" i ich teksty, które gdzieś tam czekają na odkrycie (kiedyś mówiło się, że zakurzone pergaminy leżą gdzieś w szufladzie a dziś można napisać, że niezakurzone PDFy czekają na odkrywcę gdzieś na drugiej stronie wyników z googla). I dziś własnie taki bardzo ciekawy moim zdaniem tekst chciałbym pokazać : "On the cruelty of really teaching computing science" - prof. dr. Edsger W. Dijkstra

Oczywiście każdy może sobie coś napisać w necie i podpisać to Dijekstra albo Pałlo Kohelio ale generlanie ów tekst jest wspominany na wielu innych stronach i doczekał się własnych opracowań (chociaż i nie takie rzeczy koledzy od pozycjonowania potrafią zrobić)

mentalna cela metafory

Generalnie artykuł cały nadaje się do zacytowania dlatego zalecam jego samodzielną lekturę - tutaj jedynie chciałbym się skupić na jednym bardzo ciekawym poruszonym tam aspekcie - nowości radykalnej

Jest to o tyle ważne, że dosyć często mamy taką oto groteskową sytuację :

Dużo oprogramowania powstaje w firmach, które zbudowane są w oparciu o tzw. "piramidę władzy" gdzie sformułowanie "N raportuje do M" oznacza, że niejako M ma nadaną odgórnie "moc decyzyjną" i "deleguje" a N w raportach mówi jak te delegacje/targety realizuje. A, że głównym nośnikiem energii w tychże instytucjach jest hajs zwany "budżetem" - toteż mamy sytuację, gdzie przenika się kilka dziedzin wiedzy. A sami z własnych obserwacji możemy pomyśleć ile znamy osób, które opanowały w sposób profesjonalny chociaż by jedną dziedzinę nie mówiąc o kilku...

No i zazwyczaj ci ludzie co mają budżet i stoją wyżej w piramidzie nie mają wiedzy technicznej ale jednocześnie instytucja w której pracują wymaga od nich aby wzięli odpowiedzialność za realizację zadań w poziomach poniżej. Jest to temat rzeka. W każdym razie ze względu na złożoność zagadnienia - jakim jest tworzenie programu - przekaz musi być uproszczony do form znanych temu co ma budżet i pojawiają się zubożone porównania, z których jednym z najbardziej debilnych jest "budowanie systemu to budowanie domu a programiści to murarze"

Nowość radykalna

I tutaj czas aby wspomóc się tekstem Dijekstry, w którym opisuje skąd biora się te metafory i jakie są z nimi problemy.

"The usual way in which we plan today for tomorrow is in yesterday's vocabulary(..)Of course, the words and the concepts don't quite fit because our future differs from our past, but then we stretch them a little bit(...)by means of metaphors and analogies we try to link the new to the old, the novel to the familiar. Under sufficiently slow and gradual change, it works reasonably well; in the case of a sharp discontinuity, however, the method breaks down..."

"the analogies become too shallow, and the metaphors become more misleading than illuminating"

W ramach jakiej metafory pracujemy na co dzień? Słowo klucz to Architektura i nazwa stanowiska Architekt - skąd one się wzięły?. Za wikipedią

"Architektura (łac. architectura, od architector – buduję)– sztuka i technika budowania w celu realizacji praktycznych i artystycznych wymagań ludzi cywilizowanych. Wyróżnia się architekturę miejską i wiejską a także sakralną i świecką (obronną, mieszkalną, budowli gospodarczych, budowli ogrodowych, budowli użyteczności publicznej)"

Możecie sobie sami wyszukać stronkę. O komputerach tam za dużo nie ma.

No dobra idziemy dalej - jak wpiszemy "Architektura komputera" to naszym oczom ukaże się taka definicja :

"Architektura komputera – sposób organizacji elementów tworzących komputer. Pojęcie to używane jest dosyć luźno. Może ono dzielić systemy komputerowe ze względu na wiele czynników, zazwyczaj jednak pod pojęciem architektury komputera rozumie się organizację połączeń pomiędzy pamięcią, procesorem i urządzeniami wejścia-wyjścia."

"Pojęcie to używane jest dosyć luźno" - dlaczego luźno? Może dlatego, że jest ono zapożyczone z zupełnie innej nie do końca pasującej dziedziny?

No ale to co nas najbardziej interesuje : https://pl.wikipedia.org/wiki/Architektura_oprogramowania

"Architektura oprogramowania – podstawowa organizacja systemu wraz z jego komponentami, wzajemnymi powiązaniami, środowiskiem pracy i regułami ustanawiającymi sposób jej budowy i rozwoju.

Opis architektury oprogramowania (ang. Software Architecture Description) postrzegany jest jako platforma porozumiewania się wszystkich osób zaangażowanych w proces wytwórczy systemów informatycznych.

Architektura oprogramowania jest stosunkowo młodą dziedziną informatyki i że choć w ostatnich dwóch dekadach dość mocno się rozwinęła i nawet osiągnęła poziom dojrzałości, to nadal trwają dyskusje nad jej miejscem w informatyce, a przede wszystkim nie ma zgody szerokiego gremium w zakresie określenia samej definicji architektury oprogramowania."

Jest trochę takiego bełkotu w stylu "platforma porozumiewania się wszystkich osób zaangażowanych w proces wytwórczy systemów informatycznych". Ale najważniejszy jest fragment o tym, że tak naprawdę nie ma definicji czyli nie wiadomo co to tak naprawdę jest!

- Marzena dostałem awans!
- super, kim teraz będziesz?
- architektem IT
- a co taki architekt robi?
- Nie wiadomo bo nikt przez ostatnie 40 lat tego nie zdefiniował!

Oczywiście nie mam tutaj racji bo korpo mają bardzo ładnie zdefiniowaną przez hry ścieżkę kariery (rym! jak się ostatnie zdanie odpowiednio wypowie jest rym!) i sam wdziałem na stronie - takie ładnej z profesjonalnymi stylami - że do obowiązków architekta należy spędzanie 40% na meetingach (autentyk, to jest ku*wa autentyk!!!).

W każdym razie wracając do metafor to podobno jakieś kluczowe rzeczy zadziały się pod koniec lat sześćdziesiątych - były dwie duże konferencje - zdaje się, że sponsorowane przez NATO (ciekawe czy mieli stoisko z napisem "we are hiring") i tam się te terminy jak "Architektura systemu informatycznego" czy "metodyka wodospadu" pojawiły. Ogólnie ciekawe czasy to musiały być. W lekturze często spotyka się termin "software crisis" odnośnie tamtych czasów - jeśli wtedy był kryzys to co my niby teraz mamy!?!

Inne metafory

Ogród - to się pojawia co jakiś czas w różnych artykułach a kolega miał nawet w stopce "Software Gardener". W sumie jak zostawimy budynek tak sam sobie na jakiś czas to zacznie się on rozlatywać - jak zostawimy program tak sam sobie - no to nic się w sumie nie dzieje (no dysk za pinset lat się rozleci ale to już tzw. "life span" przekracza) - no i domu nie można skopiować bezkosztowo!. Natomiast tzw. dług techniczny (który jest kolejną metaforą!) można porównać do chwastów.

Inna ciekawa metafora - Programming as Theory Building. Kawałki programu jako dowody, które wspierają wyprowadzanie nowych dowodów.

Generalnie gdyby tak się temu przyjrzeć co robimy to słowo komputer pochodzi od angielskiego computer i generalnie kiedyś to był tzw. Human Computer.

The term "computer", in use from the early 17th century (the first known written reference dates from 1613), meant "one who computes":

"Who computes" a to compute znaczy "obliczać". I nagle w kontekście obliczeń najpierw wykonywanych ręcznie, później na lampach i w końcu krzemie - gdzieś tutaj nagle pojawiają się analogie do budownictwa... oj musiało być ostre jaranie na tych konferencjach ... albo LSD! w sumie wtedy LSD chyba było legalne - co jeśli korzenie obecnych dogmatów branży IT tkwią w zajebistej imprezie LSD 50 lat temu!!!

"Inne fajne cytaty"

"A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."

"one has to approach the radical novelty with a blank mind, consciously refusing to try to link it with what is already familiar, because the familiar is hopelessly inadequate."

The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

Na szczęście ilość linii kodu wyleciała (chyba wszędzie) z targetów zwanych "Kej Pi Ajem (KPI - Key performance coś tam)" ale fakt, że taka patologia miała miejsce doskonale pokazuje skalę niezrozumienia tej dziedziny jaką jest programowanie.

"Again, I have to stress this radical novelty because the true believer in gradual change and incremental improvements is unable to see it. For him, an automatic computer is something like the familiar cash register, only somewhat bigger, faster, and more flexible. But the analogy is ridiculously shallow: it is orders of magnitude worse than comparing, as a means of transportation, the supersonic jet plane with a crawling baby, for that speed ratio is only a thousand."

O różnicy pomiędzy codziennym życiem analogowym i nową formą cyfrową :

"To this I should add that, to the extent that we view ourselves as mechanisms, we view ourselves primarily as analogue devices: if we push a little harder we expect to do a little better." (...) "it has unavoidably the uncomfortable property that the smallest possible perturbations —i.e. changes of a single bit— can have the most drastic consequences"

"also (...) quality control continues to be distorted by the reassuring illusion that what works with other devices works with programs as well. It is now two decades since it was pointed out that program testing may convincingly demonstrate the presence of bugs, but can never demonstrate their absence. After quoting this well-publicized remark devoutly, the software engineer returns to the order of the day and continues to refine his testing strategies, just like the alchemist of yore, who continued to refine his chrysocosmic purifications."

"What is a program? Several answers are possible. We can view the program as what turns the general-purpose computer into a special-purpose symbol manipulator, and does so without the need to change a single wire (This was an enormous improvement over machines with problem-dependent wiring panels.) I prefer to describe it the other way round: the program is an abstract symbol manipulator, which can be turned into a concrete one by supplying a computer to it."

"It really helps to view a program as a formula. (...) it puts the programmer's task in the proper perspective: he has to derive that formula. (...) he has to derive that formula, he has to derive that program. We know of only one reliable way of doing that, viz. by means of symbol manipulation. And now the circle is closed: we construct our mechanical symbol manipulators by means of human symbol manipulation."

"Hence, computing science is (...) the interplay between mechanized and human symbol manipulation, usually referred to as "computing" and "programming" respectively. An immediate benefit of this insight is that it reveals "automatic programming" as a contradiction in terms. A further benefit is that it gives us a clear indication where to locate computing science on the world map of intellectual disciplines: in the direction of formal mathematics and applied logic, but ultimately far beyond where those are now, for computing science is interested in effective use of formal methods and on a much, much, larger scale than we have witnessed so far."

Podsumowanie

"Well, when all is said and done, the only thing computers can do for us is to manipulate symbols and produce results of such manipulations. From our previous observations we should recall that this is a discrete world and, moreover, that both the number of symbols involved and the amount of manipulation performed are many orders of magnitude larger than we can envisage: they totally baffle our imagination and we must therefore not try to imagine them."

No to był jeden z tych trudnych odcinków, gdzie coś trzeba skrytykować by pobudzić czytelnika do myślenia. Mamy zdefiniowany jakiś mainstream - dyskutuje się w ramach mainstreamu ale mało dyskutuje się z mainstreamem. Tworzymy w naszych umysłach model rzeczywistości gdzie jedne tezy opierają się na innych i te na innych i tak dalej aż do momentu gdzie przestajemy drążyć głebiej i przyjmujemy wytłumaczenia takimi jakie są.

To ciekawe czy ludzie żyjący w czasach rewolucji naukowo/kulturalnych wiedzieli, że żyją w czasach rewolucji naukowo/kulturalnych? Czy żyjemy w takich czasach? Jeśli tak to czy nie warto przyjrzeć się bliżej osadzonym wiele lat temu fundamentom obecnych przekonań?

"Because no endeavour is respectable these days without a TLA (= Three-Letter Acronym), I propose that we adopt for computing science FMI (= Formal Methods Initiative)"