Uzupełnianie przysłowiowej luki

-- środa, 08 lipiec 2009

Ten prawie bezbłędny proces mapowania jest uniemożliwiony translacją. Przy rozwiązywaniu problemów inżynier rozpoczyna swoja pracę w świecie rzeczywistym, a kończy w świecie fizycznym. Wszelkie translacje, które dokonywane są w tym procesie, mogą sprawić, że ludzie przesuwani są do obszaru znajdującego się daleko od fizycznej/realnej rzeczywistości, w którym większość z nich ma najlepsze intuicje czy poglądy. Na przykład, spłaszczenie problemu fizycznego w słowa tylko dlatego, że końcowy program komputerowy będzie się z nich składał, to właśnie tego typu translacja. Stanowi to niepotrzebne obejście. Przekładanie świata w słowa, lub z jednego języka do innego, zawsze będzie prowadzić do powstania pomyłek i pewnych strat. Minimalizowanie translacyjnych i konceptualnych obejść stanowi rzeczywisty cel. Dlaczego więc kod komputerowy nie może zostać zaprezentowany w sposób graficzny? Graficzne pakiety modelowania, jak np. LabVIEW, Simulink, PSpice i inne, wydają się być bardziej przystępne do celów modelowania i wprowadzania realnych systemów, ponieważ pokazują przepływ energii i informacji wśród prawdziwych komponentów, utrzymując jednocześnie topografię problemu.

Dlaczego więc nie istnieje inżynier programista? Moim zdaniem, wynika to ze sposobu, w jaki takie języki komputerowe mapują (patrz schemat). Chociaż Assembly i C znakomicie mapują w ramach danego problemu, nie są w stanie mapować doświadczeń większości inżynierów, ani młodych ani starych. Biorąc to pod uwagę, inżynier będzie wolał trzymać się z daleka od czegoś, co sprawia, że czuje się niepewnie. Jeśli narzędzie komputerowe może dokładnie zmapować problem dla rozwiązania hardware’owego, a równocześnie umożliwić , aby każda kolejna abstrakcyjna warstwa była usuwana aż do poziomu samego bitu, inżynier będzie w stanie jednocześnie być specjalistą inżynierem i specjalistą od oprogramowania. Jest to narzędzie, które na pewno byłoby używane przez starszego i młodszego inżyniera…… jeśli je znajdziemy.