Dyskusja:Błąd (informatyka)

message: Znam tylko jednego człowieka, który mówi "dibadżer"... hy hy... Nie myślałem, że to częsty błąd.
--Lorn 10:31, 20 lut 2005 (CET)
[[
== jest tylko jeden bug. DE Bug. ==]]'''

message: Cyt hasła: "W żargonie informatycznym, wyrażenie Bug oznacza pewien błąd, usterkę - niepożądane, powtarzalne działanie programu, wynikające z błędu człowieka na jednym z etapów tworzenia oprogramowania, zwykle na etapie projektowania lub tworzenia kodu źródłowego."
replies: text: Nie wiem czy to nie zawęża znaczenia - w końcu niektóre programy celowo działają w pewnym sensie niepowtarzalnie (np. modelowanie Monte Carlo), a wiele po prostu działa w środowisku które jest niepowtarzalne, i taki bug może się objawiać b.rzadko - w końcu gdyby było inaczej, to wszystkie programy dałyby się przetestować a np. program ZUS-u byłby też OK. Moze dodać jakiś "kwalifikator"? Np. "... powtarzalne (w identycznych warunkach) ..."
AWM~ads 10:40, 9 mar 2005 (CET)

text: "Powtarzalne" w sensie: uruchom program, kliknij tu i tu, wpisz to, a to, a zobaczysz, że się wywali. Błędy wynikające z wad nośnika, pamięci, procesora (np. od przegrzania, promieniowania kosmicznego czy czarnego voodoo) nie są powtarzalne w tym sensie i nie są bugami oprogramowania. "Powtarzalne" nie znaczy tu "powtarzające się stale", tylko "dające się powtórzyć, prześledzić", co nie oznacza "widoczne od razu". Co do Monte Carlo - miałem bardzo rzadko zdarzający się bug w pseudolosowej symulacji. Wiedziałem jak go usunąć dopiero, gdy wyczułem  w jakich sytuacjach się zdarza. Wcześniej zdarzyło mi się to dwa razy, ale udało mi się sztucznie wytworzyć takie parametry symulacji, żeby się zdarzało prawie zawsze: było to "powtarzalne" zjawisko, więc bug. Jestem za kwantyfikatorem, ale jakimś jasnym: "... niepożądane, powtarzające się w określonych warunkach,...", "występujące w określonej sytuacji...", "dające się prześledzić", a może dobrze jest jak jest? Możemy też pominąć powtarzalność na początku, a rozwinąć temat przy dibadżerach.
--Lorn 23:14, 10 mar 2005 (CET)
replies: text: :Jestem za - właśnie o to mi chodziło. Dowolne z kwantyfikatorem będzie (dla mnie) OK AWM~ads 23:22, 10 mar 2005 (CET)
thread_title:  Czy "bug" naprawdę zakłada powtarzalność? 

message: Dodałem jeszcze trochę nt. złożoności testowania. Nb. nie wiem czy określenie "Prewencja" jest tutaj najlepsze - trochę kiepsko się kojarzy - może po prostu "Zapobieganie błędom", "Metody zapobiegania błedom" + "Dobre praktyki programowania" (kalka z ang. - nie wiem jak po polsku będzie ładnie)
AWM~ads 10:43, 11 mar 2005 (CET)
replies: text: Musimy dyskutować każde słowo? Pisałem to późno w nocy i jestem otwarty na wszelkie poprawki. Zmieniaj, poprawiaj. Mam tylko zastrzeżenie co do celowości wprowadzenia wzmianki o problemie komiwojażera. Istnieje bardzo proste programistycznie rozwiązanie problemu, z oczywistym dowodem poprawności: sprawdzić wszystkie możliwe permutacje (koniec rozwiązania, koniec dowodu). Chciałeś chyba napisać, że sprawdzanie wszystkich możliwych wejść, żeby udowodnić poprawność programu, można porównać do tego rozwiązania - nawet przy małej wielkości wejścia, czas sprawdzania jest ogromny. Ale zanim to jest dobrze wyjaśnione, nagle pojawia się porównanie suboptymalnych rozwiązań do sprzedawania dziurawego oprogramowania. Czy naprawde wszyscy czytelnicy wikipedii znają problem komiwojażera na tyle, żeby zrozumieć porównanie? I czemu komiwojażer, a nie jakikolwiek inny problem NP-trudny? A może wcale nie opowiadajmy bajek, tylko napiszmy, że "czas sprawdzania wszystkich możliwości wzrasta wykładniczo względem złożoności programu i podobnie jak w przypadku innych problemów NP-trudnych, stosuje się rozwiązania suboptymalne"? Tak prosto z mostu...
--Lorn 17:13, 11 mar 2005 (CET)
Weryfikacja nie jest tam NP-trudna, jest nierozstrzygalna. Przybliżone metody weryfikacji są częśto exptime-zupełne czy coś raczej w tych okolicach, a nie po prostu NP. Najlepiej w ogóle o tym nie pisać. Taw 17:44, 11 mar 2005 (CET)
thread_title:  Złożoność testowania, Dobre praktyki programowania 

message: "języku wyższego poziomu (np. Perl czy Python) będzie miał mniej bugów niż w języku niższego poziomu (Java, C, czy asembler)."
Java jest językiem niższego poziomu? Od kiedy? Nie jestem też pewien czy C powinno tak zostać zakfalifikowane...
C jeszcze tak, ale Java z całą pewnością nie. 83.21.147.69 (dyskusja)
thread_title:  Java językiem niżsego poziomu? 

message: I'm sorry that I can't speak Polish but Błąd (informatyka) looks like a duplicate of this article; perhaps a merge is due. --194.226.235.251 14:59, 20 paź 2005 (CEST)
thread_title:  To merge with [[Błąd (informatyka)]] 

message: czy Bug aby na pewno czyta się "bag"??
replies: text: Tak. Longman podaje wymowę bʌg. Ponadto odsłuchałem i wyraźnie słyszę "a". Pzdr., Ency (replika?) 11:56, 31 lip 2008 (CEST)
thread_title:  Błąd w błędzie? 

message: W haśle pojawił się taki wpis:
replies: text: Po polsku precyzyjni programisci bug nazywaja ciem  , bo byla to ćma smiec lub samica, co dodatkowo sie kojarzy ze - chwilową ciemnotą czy nieuwagą - powodem błędu autora programu.
Wycofąłem i przeniosłem tutaj, bo nieuźródłowione, a ja nigdy o tym  nie słyszałem (co oczywiście nie jest przesądzające). Wie ktoś coś o tym? 2010-02-04T10:23:38 Ency (uzupełniłem zapomniany podpis Ency (replika?) 22:13, 4 lut 2010 (CET))

text: Moim zdaniem ściema. rzyjontko (dyskusja) 20:15, 4 lut 2010 (CET)
replies: text: :No to mamy już 2:0. Pzdr., Ency (replika?) 22:13, 4 lut 2010 (CET)
Jak dotąd nie udało mi się zweryfikować nie tylko płci tego ćma ale nawet do jakiego należny gatunku. Gatunek jest istotny by w entomologii zweryfikować kwestie etymologi . 
Ściem owszem używany, bardziej samo-refleksyjnie. 
*np: Co robisz ciem-je-m albo odciemmiam. Czasami akcentowane z zachwytem -mniam (maniera źle widziana u precyzyjnych)
*o kurde ale ściem (się zrobił ciem, w czacie s'ciem). 
Ogólnie żeby nie jeść ciem (nie odciemiać) trzeba mieć ciem-je-nie.
aka wzór: cimienie <=> nie ciemje OR ciemje <=> nie ciemienie; i=j  Poz, Vednar (dyskusja) 06:04, 5 lut 2010 (CET)

text: Fajna zabawa słowami, ale plwiki to nie pole do ćwiczeń a'la Masłowska, i w ogóle cała powyższa wypowiedź jest nie na temat. Proszę o konkrety (źródła, a  nie dywagacje o swoich obserwacjach) lub wybranie sobie innego forum. Ency (replika?) 11:23, 5 lut 2010 (CET)
thread_title: Ciem?

message: No właśnie. Od kiedy błędy składniowe nazywa się bugami? Proponuję rozdzielenie tych dwóch tematów lub zmniejszenie udziału hasła "bug" w tym artykule, bo teraz sugeruje on, jakoby np. literówka w kodzie była bugiem. --194.181.22.3 (dyskusja) 05:53, 1 cze 2011 (CEST)
* We współczesnym programowaniu błąd składniowy może stać się "bugiem" za sprawą złożonego procesu tworzenia kodu z udziałem różnych meta-języków. Kiedyś błąd tego typu dało się łatwo odsiać w procesie kompilacji (bo ją np. uniemożliwiał), dziś może się zdarzyć, że błędny kod wejdzie do wersji dystrybucyjnej jakiegoś pakietu źródłowego lub biblioteki - choćby za sprawą systemów numerowania wersji i omyłkowego oznaczenia wersji wadliwej jako stabilnej. Np. w pakietach linux gentoo (źródłowych) często błędy składniowe są nazywane bugami. Nie wiem, na ile jest to prawidłowe, ale takie są realia. Trzeba też pamiętać, iż często to nie skompilowany kod jest produktem (komercyjnym np.) ale np pliki źródłowe albo określony ich podzbiór. Tescobar/dyskusja 10:38, 1 cze 2011 (CEST)
thread_title:  Błędy składniowe bugami?