Witam
Ostatnio zastanowiła mnie pewna kwestia. Mianowicie dlaczego w programowaniu (i ogółem informatyce) powstaje tyle różnych do wykrycia błędów? Pisząc pętlę nie mam żadnej pewności, że będzie działała - mogę opierać się jedynie na intuicji. Formalne metody dowodzenia algorytmów przy większych aplikacjach są bezużyteczne a przy średnich baaardzo czasochłonne i skomplikowane więc w w efekcie również bezużyteczne. Programy sypią się na każdym kroku, nieważne czy projekt jest komercyjny czy amatorski. Informatyka pod tym względem wypada naprawdę marnie w porównaniu z innymi dziedzinami inżynierii takimi jak budownictwo. Domy, mosty i inne konstrukcje nie walą się nikomu na głowy (poza parymi skrajnymi przypadkami, gdzie zazwyczaj celowo ograniczano wydatki). Wszystko jest jakby bardziej przemyślane i dopracowane. Natomiast w informatyce w nawet najbardziej komercyjne projekty są często dziurawe jak ser szwajcarski - chyba najlepszym tego dowodem są systemy operacyjne. Powstają kolejne języki ponoć coraz bardziej bezpieczne, a sytuacja jakoś za bardzo się nie poprawiła. Co jest przyczyną takiego stanu rzeczy?
Mi się wydaje że przez to że wszytsko tworzą ludzie którzy jak wiadomo nie są doskonali :)
revcorey napisał(a)
Mi się wydaje że przez to że wszytsko tworzą ludzie którzy jak wiadomo nie są doskonali :)
A budowniczowie są doskonali? A jednak domy niecodzień walą się ludziom na głowę. Coś innego musi być tego powodem...
Podałeś przykład budownictwa - dobrze.
Poszukaj, jak wyglądało budownictwo, we wczesnym stadium rozwoju. Nie mówię od razu o ziemiankach, ale wiesz jak np były budowane w średniowieczu gotyckie kościoły? Przez cały okres modlono się, żeby wszystko nie posypało się w ch... Mimo to, często gęsto sypało się. To, co podziwiasz jako trwałe i nienaruszalne, jest z reguły na tyle delikatne, że jeden pożar całą katedrę kładzie na kolana.
Porównaj z dniem dzisiejszym - mamy wieżowce, które po uderzeniu i eksplozji samolotu się trzymają (przynajmniej przez jakiś czas) - a to już jest niezła akrobatyka.
Czyli wiek danej dziedziny, zebrane w niej doświadczenia itp ma znaczenie. Programowanie nawet stu lat nie ma. Poważne programowanie nawet 50-ciu. Cały czas wchodzą nowe idee i technologie, które są na bieżąco testowane przez życie. Można nawet powiedzieć, że w obecnej chwili programowanie to jeden wielki eksperyment, który od czasu do czasu coś praktycznego przy okazji udostępnia :]
IMHO
Projektowanie i budowa budynków wcale nie przebiega zawsze tak jak powinna. Co i rusz słyszy się o błędach konstrukcyjnych lub wykonawczych podczas budowy budynków czy autostrad. Ostatnio głośno było o błędach w projekcie już zbudowanego amfiteatru w Płocku grożącego zawaleniem albo o minięciu się drogi z mostem gdzieś w Grecji. W zeszłym roku głośno było o zawaleniu się hali w Katowicach gdzie były ofiary śmiertelne. Okazało się, że poza błędami konstrukcyjnymi, użytkownicy niewłaściwie eksploatowali budynek i nie zlecili w odpowiednim czasie odśnieżania budynku.
W przypadku budownictwa rozdział obowiązków przy tworzeniu jakiegoś projektu architektonicznego jest rozłożony pomiędzy architekta, kierownika budowy, murarzy, pomocników itp. poza tym są jakieś przepisy, normy budowlane. Tymczasem pisanie aplikacji i systemów operacyjnych często przebiega w taki sposób w jaki wyglądałoby projektowanie, nadzór i wykonanie już na placu budowy, wszystko na raz. Twórcy oprogramowania często poświęcają za mało czasu na projektowanie jeszcze przed rozpoczęciem budowy aplikacji co jest przyczyną późniejszych problemów z wydajnością, wycieków pamięci itp. Wiąże się z tym też presja jaką obciążają wydawcy, producenci twórców oprogramowania. Dla producentów liczy się przede wszystkim szybkość, a nie dokładność. Naciskają programistów na dotrzymywanie terminów tzw. deadlin'ów i chcą oglądać szybkie efekty. Nie raz dochodziło do sytuacji, że pod wpływem producentów wypuszczano program czy grę w momencie gdy jeszcze trwały beta-testy jako wersję finalną.
Kolejna sprawa to znacznie większy stopień komplikacji i złożoności w sferze projektowania, nadzoru i wykonania oprogramowania niż w przypadku budownictwa. Ponadto często działanie aplikacji zależy od konkretnej architektury, systemu operacyjnego oraz innych programów! Widziałem sytuacje gdzie prosta aplikacja wieszała się w trakcie działania w tle jednej z wersji playera mp3. Aplikacja na 100% była napisana dobrze, a autor zadbał o poprawne deklarowanie i zwalnianie pamięci itp. To player mp3 miał jakieś wycieki pamięci, które powodowały błędy krytyczne w działaniu tej aplikacji.
/edytka: Poza tym ja bym nie porównywał błędów w działaniu aplikacji do walenia się budynku. Przecież po restarcie aplikacji, ew. systemu masz ją z powrotem często także z zachowanymi efektami pracy gdzieś w kopii zapasowej. Najczęstsze błędy aplikacji to raczej coś jak przeciekanie dachu, niedostateczna izolacja, wilgoć itp. To przecież bardzo częste skutki błędów konstrukcyjnych występujących w budownictwie.
bo zeby zaprojektowac legalnei dom w ktorym moze ktos mieszkac trzeba miec pare lat studiow za soba natomiast zeby stworzyc program trzeba umiec czytac i miec przynajmniej jedna sprawna konczyne z wyjatkiem tej w spodniach chociaz..
a co do petli to MASZ pewnosc ze bedzie dzialac tak jak myslisz jak KONTROLUJESZ to co piszesz, poza tym to sie pozniej testuje :P
bo zeby zaprojektowac legalnei dom w ktorym moze ktos mieszkac trzeba miec pare lat studiow za soba natomiast zeby stworzyc program trzeba umiec czytac i miec przynajmniej jedna sprawna konczyne z wyjatkiem tej w spodniach chociaz..
A co to ma do rzeczy? Myślisz, że firmy type Borland czy Microsoft zatrudniają studencików za parę groszy?
a co do petli to MASZ pewnosc ze bedzie dzialac tak jak myslisz jak KONTROLUJESZ to co piszesz, poza tym to sie pozniej testuje
Jesteś w błędzie, jeżeli myślisz, że masz kontrolę nad tym kodem. Jeżeli nie można dowieść poprawności matematycznie czy w jakikolwiek inny, naukowy sposób nie możesz mieć pewności, że dla KAŻDEJ sytuacji program będzie działał. Argument z testami jest idiotyczny - ciekawe jak przetestujesz program, którego dane wejściowe mogą się układać w 2^n kombinacji. Możesz co najwyżej zrobić testy częściowe, które zależą od pomysłowości testerów.
skoro nie masz matematycznej pewnosci ze cos zadziala to jak mozesz cos takiego zaimplementowac?
Właściwie da się przeprowadzić "matematyzacje" każdego algorytmu, ba nawet pełnego programu. Sam czasem tak robiłem gdy się kończyły mi pomysły i "ratowały" mnie te wzorki, ale to już jest akt desperacji. W praktyce jest tak że się po prostu robi tak jak się uważa i powinno działać. Im więcej wiesz i masz więcej doświadczenia tym lepiej bo mniejsze prawdopodobieństwo popełnienia trywialnego błędu, za to monotonia może sprawić że będziesz robic trudne do wykrycia błędy. Przez to właśnie są potrzebni beta-testerzy.
A co do porównania do budownictwa to jaki to ma sens? W budownictwie jest cholernie dokładny projekt, panowanie materiałowe itp, także każdy szczegół stara się sprawdzić, ale i tak wychodzą często klocki, że dach się nagle zawala bo nie przewidziano maksymalnego obciążenia...
skoro nie masz matematycznej pewnosci ze cos zadziala to jak mozesz cos takiego zaimplementowac?
A normalnie: na czuja / metodą prób i błędów / dopisując do prostego kodu nowe fragmenty i sprawdzając, czy zmiany robią to, czego się spodziewasz / itd
Jest 1001 sposobów.
I co tu dużo mówić, napisałem wiele tysięcy linii kodu, który był dogłębnie testowany i uważam go za działający. A dowodu formalnego jeszcze nie przeprowadziłem ani jednego. Nawet dla czysto matematycznych albo trywialnych zagadnień: losowania liczb, szukania liczb pierwszych, czy chociażby wyszukiwania liniowego.
Dowodzenie wydaje ci się proste? To przeprowadź dowód formalny chociażby dla takiej pętli. IMHO, na jednej stronie się zmieścisz, jak masz drobne pismo:
int n;
cin >> n;
for(int i=1; i<=n; i++) if(i%2==0 || i&&3==0) cout << i << endl;
ale ja nie mowie o dowodzeniu :| fakt jak chcesz byz w 100% pewny to dowod ma sens ale mi chodzi o intuicje matematyczna ze np: ograniczasz dane wejsciowe do znanego ci poziomu i wzgledem nich tworzysz pozniej kod ktory w takim zakresie masz pewnosc ze dziala, a inne dane zostana po prostu odrzucone, oto mi biega...
W przypadku budynku też nie masz gwarancji, że dla każdej sytuacji się nie posypie.
A co jak spuszczą bombę atomową?
Na ogół, oprogramowanie musi być wystarczająco dobre a nie idealne. Jakość jest priorytetem jedynie w nielicznych przypadkach: sterowanie w elektrowni atomowej, lotnictwo, promy kosmiczne itp. Tam się tworzy oprogramowanie inaczej niż na PCty - stosuje się design by contract, systemy do automatycznego częściowego dowodzenia poprawności, dokumentuje się absolutnie wszystko, budżet jest taki, że głowa boli, nigdy pojedyncza osoba nie pracuje nad jakimś odpowiedzialnym fragmentem. No i zatrudnia się o niebo lepszych (i droższych) specjalistów niż przy produkcji powiedzmy... komunikatora internetowego, czy nawet systemu operacyjnego ogólnego przeznaczenia.
Większość firm robi soft studentami lub dopiero-co magistrami.
I jeszcze jeden aspekt na korzyść budownictwa: w budownictwie musisz mieć UPRAWNIENIA, w informatyce nie.
Dochodzi jeszcze kwestia precyzji. Budujac taki np. wiezowiec jak postawisz jeden slupek o 5cm dalej niz w planie to sie nic nie zawali i pewnie nawet nikt nie zauwazy, bo konstrukcja pozniej bedzie polaczona tak, ze sie to wszystko zejdzie do kupy nawet jak nie jest ukladane milimetrowa linijka.
W programowaniu tez tak czasem bywa, ze sie bierze jakis margines niekoniecznie myslac o tym czy jest ok - np. przyjmujesz zakres inta za dobra monete i sie okazuje po 5 latach, ze sie niestety machnales. Ale jest wiele sytuacji gdzie i< 10000 to nie to samo co i <= 10000 i pare takich bledow potrafi sie tak rozpropagowac, ze aplikacja lezy i kwiczy...
No i tak jak mowi reszta - amator nie zbuduje domu, a aplikacje owszem.
johny_bravo napisał(a)
Dochodzi jeszcze kwestia precyzji. Budujac taki np. wiezowiec jak postawisz jeden slupek o 5cm dalej niz w planie to sie nic nie zawali i pewnie nawet nikt nie zauwazy, bo konstrukcja pozniej bedzie polaczona tak, ze sie to wszystko zejdzie do kupy nawet jak nie jest ukladane milimetrowa linijka.
Właśnie jak popełnisz taki drobny błąd lub źle dobierzesz materiał, to skutkami mogą być właśnie wilgoć, brak dostatecznej izolacji cieplnej, przeciekanie dachu i inne, a wszystko jest świetnie ukryte pod grubą warstwą cementu, tynku, tapety czy kafelek. Wady w budownictwie często wychodzą po latach już w trakcie użytkowania i nie rzucają się tak w oczy. Jeżeli ktoś mieszka w blokach z płyty to pewnie zna te wszystkie przypadki ścian, które nie trzymają się pionu, wilgoć itp. Może być znacznie gorzej jeśli okaże się, że w ścianach jest azbest albo jakieś inne szkodliwe g*wno (podobno większość mieszkań komunalnych np. w Berlinie ma w ścianach albo na dachu azbest i dopiero teraz po 30-40 latach to usuwają lub burzą budynki jak już ludzie zaczynają chorować.
Wszędzie tam gdzie jest czynnik ludzki jest ryzyko błędu. Także wśród elity z najlepszych uniwersytetów są przypadki i to nie rzadkie, że ludzi zwyczajnie z rozkojarzenia, zmęczenia, nadmiaru obowiązków, stresu itp. nawalają i popełniają błędy lub idą na skróty. Nikt nie jest nieomylny i z pewnością nie jest to kwestia czy ktoś jest amatorem czy mózgiem z pięcioma fakultetami. Jestem też przeciwny opinii , że programy nawalają bo piszą je debile, którzy mają sprawną tylko jedną rękę jak to sugeruje cepa. Sądzę, że takie krytyczne opinie autora wątku pod adresem informatyki jako dziedziny wyjątkowo podatnej na błędy nie są efektem używania programów open-source od amatorów ale raczej komercyjnego i drogiego oprogramowania firm takich jak Borland, Microsoft i innych, które niewspółmiernie do zainwestowanych środków wyjątkowo często zawodzą. Przecież jeśli Microsoft zatrudnia co roku w Polsce tylko kilku najlepszych studentów Politechniki Gdańskiej to te ich oprogramowanie powinno być bezawaryjne i niezawodne, jednak daleko mu do tego. Mogę zgodzić się tylko, że amatorzy i doświadczeni programiści nie popełniają takich samych błędów i zdecydowanie rzadziej proste błędy popełniają ci drudzy. Jednak ostatni przykład oprogramowania Borlanda
>>>LINK<<<, które zaśmiecało pamięć pokazuje, że nawet zawodowcom zdarzają się takie prozaiczne błędy jak zapomnieć zwolnić pamięć.
może po części wpływ ma to, iż ilość czynników wpływających na oprogramowanie jest większa i w dużej części nieprzewidywalna (ciekawski użytkownik, cały czas rozwijane systemy zewnętrzne, aktualizowany system operacyjny), a prowadzenie testów na wszystkich poziomach, także testów mających na celu nie sprawdzenie, czy oprogramowanie realizuje wymagania, lecz wyszukiwanie w nim błędów, jest nieopłacalne dla większości projektów.
Nie używam tylko aplikacji komercyjnych - mam zarówno windowsa jak i linuxa. Większość aplikacji użytkowych, które mam jest open-source lub freeware. Programy się sypią niezależnie czy pisze je duża firma czy xxx użytkowników z całego świata. Linux też ma w cholere dziur i różnych bugów. A bardziej katastrofalne błędy w krytycznych systemach też się zdarzają. Teraz nie pamiętam nazwy ale nad którymś promem stracono kontrolę z powodu przepełnienia licznika. Przeprowadzono również testy różnych systemów cyfrowych (również tych bardziej krytycznych dla życia) i okazało się że 70% nie działa w pełni jak trzeba. Jest wątpliwe, że oprogramowanie dla promów kosmicznych jest pisane w pośpiechu i bez przemyślenia. To sugeruje, że z jakiegoś powodu niezależnego od kwalifikacji programistów, powstają błędy. Przykład johnego jak na razie jest najbardziej przekonywujący. Natomiast argument ze średniowiecznym budownictwem nie do końca. W średniowieczu nie posiadano dostatecznego aparatu matematycznego oraz fizycznego, żeby wznosić takie budowle. Jednakże w XX wieku matematyka stoi na wysokim poziomie i informatyka może z niej czerpać pełnymi garściami.
przyklad z budownictwem nie byl moze najlepszy, ale dajmy sobie cos, co jest bardzo zwiazane z programowaniem: elektronika
jak to sie dzieje, ze procesory nie maja bledow? dlaczego ta caala nwa technologia dziala siwetnie? - nie mowie tu o oprogramowaniu dla danych urzadzen, a samej elektronice.
Całą elektronikę analogową można opisać przy pomocy równań różniczkowych, całek i ogółem analizy. Programowanie bazuje na intuicji i zaufaniu dla programisty, więc zawsze będzie w cholere błędów. Może gdyby udało się opisać w jakiś w miarę prosty sposób zachowanie się programu, błędów było by mniej. Ale do tego chyba trzeba by kompletnie rewolucyjnego języka programowania.
Jak Ci się komp wysypie o np wywali błąd, klikniesz ok i działasz dalej, w najgorszym wypadku wyłączysz i włączysz jeszcze raz a jakby sie wysypał powiedzmy jakiś układ w pralce to trzeba pewnie dłubać, dlatego w elektronice robi się obsługę KAŻDEGO możliwego błędu. Jak robisz program i w głowie masz jakiś bardzo abstrakcyjny błąd to myśłisz: "ee mało prawdopodobne, że do tego dojdzie" no i nie ma problemu, jak do tego jednak dojdzie to sobie walną restarta, a układy jak procesor albo bardziej może układ sterujący zapłonem w aucie, czy elektronika w telewizorze nie mogą być tak tolerancyjne na błędy no bo przecież nie będziesz co chwile grzebać w zapłonie jak coś tam pójdzie nie tak, dlatego robi się dokładną obsługę każdego możliwego błędu (oczywiście można często coś przeoczyć)
Wydaje mi sie, ze w elektronice jest wszystko bardziej doprecyzowane i jednoczesnie jest wiecej miejsca na margines bledu. Jak na nozce jest 5,2V a nie 5,0 to czesto nie ma roznicy. Jak wprowadzono 230V w gniazdkach zamiast 220V to tez praktycznie zadna elektronika nie miala problemu. W programowaniu takie cos najczesciej nie przejdzie. Jak tablica jest zarezerwowana na 15 elementow to zmiesci sie w niej maksymalnie 15 i ani jeden wiecej.
Dochodzi tez ta zlozonosc, o ktorej pisal casual coder - piszemy program, ktory w aktualnej konfiguracji kompa przy 3 sterownikach roznych urzadzen z jakiegos powodu leci, po pewnej kombinacji klikniec myszka i klawiszy. Nie ma szans znalezc takich bledow samemu - po to sie robi beta testy. W odroznieniu np. od elektroniki, gdzie po wyprodukowaniu np. plytki drukowanej wystarczy kontrola napiec i przebiegu pradow w punktach kontrolnych, czy na wyjsciu. Bo jak sa poprawne to mala szansa, ze uklad nie dziala. W programowaniu testy eliminuja 60-70% bledow, nie 99%...
Urządzenia elektroniczne muszą też spełniać całą masę norm, które w programach są jedynie wskazane.
johny_bravo napisał(a)
No i tak jak mowi reszta - amator nie zbuduje domu, a aplikacje owszem.
A systemy operacyjne budują amatorzy? Rozumiem, że po studiach to wszystko wszystkim wychodzi i nie ma niedziałających pętli? :>
SdC napisał(a)
johny_bravo napisał(a)
No i tak jak mowi reszta - amator nie zbuduje domu, a aplikacje owszem.
A systemy operacyjne budują amatorzy? Rozumiem, że po studiach to wszystko wszystkim wychodzi i nie ma niedziałających pętli? :>
Oczywiscie, ze nie. BTW studia nie maja tu wiele do rzeczy. Przy wiekszym doswiadczeniu i bledy sa rzadsze (czyt. sa ich tysiace, nie miliony :) ) Do tego inzynierow budowlancow czy elektronikow pilnuja normy, czy tego chca czy nie. Imformatykow pilnuje jedynie klient - a sami wiemy jak duzo w wiekszosci wypadkow ma do powiedzenia...
W takim razie może było by dobrym pomysłem wprowadzić takie normy? Szczerze mówiąc nie uśmiecha mi się pisanie projektu dla firmy byle szybko i byle by działało a i wynik takiego podejścia jest mizerny...
nie wiem jaki sens ma ten wątek
nie wiem jak można porównywać programowanie do budownictwa
nie wiem jak miałyby wyglądać takie normy
ogólnie to nic nie wiem
// po co napisałem tego posta ? w sumie nie wiem :/
ogólnie jak nic nie wiesz to się nie odzywaj :P
POSIX napisał(a)
W takim razie może było by dobrym pomysłem wprowadzić takie normy? Szczerze mówiąc nie uśmiecha mi się pisanie projektu dla firmy byle szybko i byle by działało a i wynik takiego podejścia jest mizerny...
Nie da rady raczej wprowadzić takich norm. W pewnym zakresie firmy wprowadzają pewne normy we własnym zakresie ale i tak wszystkiego się nie da przewidzieć. W budownictwie ilość materiałów, rodzajów budulca jest ograniczona, rodzaje zapraw, klejów itp. też. W związku z tym też jest możliwe wprowadzenie takich zasad ponieważ możliwości też jest ograniczona ilość. Tymczasem w przypadku programowania zarówno budulec (komponenty, klasy itd.) oraz zaprawa (funkcje, procedury, metody, parametry) mogą być niemal dowolne i nie muszą się mieścić w żadnych standardach aby działać. Mało tego aby wymyślić coś nowego beż nowego kodu się nie obędzie i tym samym nie jest łatwo uniknąć błędów. Ponadto jest użytkownik tego oprogramowania, którego można porównać do słonia w składzie porcelany. Użytkownik zawsze wymyśli coś czego nie przewidział programista i zrobi coś co niekoniecznie jest logiczne, a tym samym nie mieści się w ramach przewidzianych w programie.
/edit: literówka
A jakie są normy w elektronice? Tam już nie można powiedzieć, że używa się wyłącznie standardowych elementów, które łączy się w standarodwy sposób. Przykładem są zasilacze i przetwornice impulsowe, które zazwyczaj posiadają masę różnych niestandardowych części dla zwiększenia wydajności.
Chyba nie ma żadnych twardych norm, po prostu każdy sie stara jak może bo klient bubla nie kupi, a czemu tak w informatyce nie jest? nie wiem
no sa normy: tanio, szybko, efektywnie ;)