Jump to content
Forum Kopalni Wiedzy

darekp

Users
  • Content Count

    1096
  • Joined

  • Last visited

  • Days Won

    27

darekp last won the day on July 3

darekp had the most liked content!

Community Reputation

69 Excellent

About darekp

  • Rank
    Lis Major

Recent Profile Visitors

8085 profile views
  1. Przyczyną wynalezienia młotka, była właśnie taka potrzeba "żeby czymś lepiej przywalić", więc nie ma żadnej "z drugiej strony". To ta sama strona przyczynowo-skutkowa. Edytowane 31 minut temu przez Sławko Z powyższym się w pełni zgadzam. Obaj (powyżej) napisaliśmy o tym samym. Że najpierw była potrzeba "przywalenia lepiej" i ona była przyczyną wynalezienia młotka. Jednakże pytanie, które napisałeś wcześniej: dla mnie zawiera (być może interpretuję coś inaczej niż Ty, ale w takim razie proszę o wyjaśnienie) mniej więcej taki przekaz: najpierw trzeba wyprodukować młotek, potem zbadać jego właściwości i dopiero po zbadaniu okaże się do czego on się nadaje. To wygląda na bardzo nieefektywny sposób tworzenia wynalazków, bo większość wynalazków, które wyprodukujemy nie zastanawiając się nad potrzebą, będzie prawdopodobnie bezużyteczna. Oczywiście w praktyce też tak się czasem zdarza, że ktoś prowadzi np. jakieś badania naukowe nie zastanawiając się nad ich praktyczną przydatnością, nawet nie wierząc, że wyniki kiedykolwiek do czegoś się przydadzą, a jednak po jakimś czasie okazuje się, że te wyniki mają znaczenie praktyczne. A poza tym... chyba Henry Ford powiedział kiedyś, że dopóki ludziom nie pokazał wyprodukowanego przez siebie samochodu, oni pragnęli mieć tylko większe i silniejsze konie:) Steve Jobs z tego co pamiętam coś podobnego powiedział kiedyś o komputerach Apple. Więc tak bywa, jest jakaś "inna strona", która czasem się przydaje (przynajmniej tak na pierwszy rzut oka to wygląda). Tylko jej przydatność jest jakby bardziej dyskusyjna. Ale, tak już jak napisałem, być może jest tu kwestia, że coś inaczej zinterpretowałem i trzeba "uzgodnić terminologię"(?)
  2. Z drugiej strony, po co wynajdywać młotek, jeśli nie ma żadnej potrzeby, którą by on zaspokajał? Mówi się, że to potrzeba jest matką wynalazków Więc pewnie można by alternatywnie powiedzieć, że badanie kwarków i reszty jest po to, aby zaspokoić naszą potrzebę np. głębszego zrozumienia lub tp. Zapewne po dokładniejszej analizie by się okazało, że jest to w dużym stopniu równoważne Waszemu sposobowi myślenia (tylko stosowanie "innego nazewnictwa"), niemniej jednak nie w stu procentach i mam wątpliwości, czy trafna jest w tym wypadku taka od razu stawiana diagnoza, że inaczej patrząca na sprawę osoba ma "problem ze zrozumieniem podstawowych zjawisk przyczynowo-skutkowych"
  3. Jakoś nie chce mi się wierzyć - koszty materiałów, testów itp. Pewnie na ludziach dałoby się zaoszczędzić mniej niż 50 %, czyli rząd wielkości pozostałby ten sam. To trochę tak jakby wierzyć, że w dużych projektach IT większość kosztów stanowią koszty pracy programistów (tak mi się kojarzy). Zapewne z połowę masy tego lądownika (czy też raczej przeznaczonej do powrotu jego części) stanowiłoby paliwo. Lądowniki Apollo wracające z Księżyca być może nie potrzebowały dużo paliwa (nie orientuję się ile, ale mała grawitacja, brak atmosfery), z drugiej strony w przypadku statków kosmicznych startujących z Ziemi większość masy stanowi paliwo (chyba coś koło 90 %). Mars jest z grubsza gdzieś w połowie pomiędzy tymi przypadkami (grawitacja ok. 1/3 ziemskiej, podczas gdy na Księżycu 1/6, a atmosfera o wiele rzadsza, ale chyba jednak nie do pominięcia).
  4. Współczuję tym dzieciakom, to jasne, że wychowywane przez sztuczną inteligencję będą psychicznymi kalekami (o ile w ogóle przeżyją taki eksperyment). Mam wątpliwości, czy samodzielnie potrafiłbym wychować dziecko (od niemowlęcia), a Ty myślisz o wychowaniu maszynowym.... W jakimś sensie (bardzo odległym), próbowano już kiedyś czegoś z tej samej kategorii: https://pl.wikipedia.org/wiki/Fryderyk_II_Hohenstauf - eksperyment deprywacyjny (Wikipedia sugeruje, że być może historycznie się nie odbył, że to tylko paszkwil wymyślony przez kronikarza, ale to w gruncie rzeczy "tym bardziej" - skoro już w średniowieczu było dla ludzi jasne, czym by się to skończyło, to pozostaje tylko ubolewać, że wykształcony forumowicz z KW nie czuje takich "subtelności").
  5. OK, w niektórych przypadkach geografia odgrywa dużą rolę uniemożliwiającą rozwój. Z drugiej strony zapewne bez problemu znajdziemy inne "niektóre przypadki", gdy pomimo kiepskich warunków geograficznych, zwłaszcza braku dużych złóż naturalnych, krajowi udało się osiągnąć dość wysoki poziom rozwoju/zamożności (będę strzelał, że przykładowo: "tygrysy azjatyckie", Japonia, Szwajcaria). Więc pewnie wychodzi na to, że czynnikiem determinującym jest rozwój, czasem wspierany warunkami geograficznymi, czasem pomimo nich, ale jednak rozwój. P.S. BTW czy z geografii nie powinno przypadkiem wynikać, że duży kraj w Europie Środkowej, położony pomiędzy Niemcami a Rosją, powinien być "z automatu" zamożny? Jakie duże możliwości zarabiania jako pośrednik, tworzenia kanałów handlowych pomiędzy jednymi i drugimi itp. (jeszcze tu trzecie Chiny można by dorzucić). A cosik mu to dość "średnio" wychodzi
  6. Ja też tego tak rozumianego "ideału piękna" nie potrafię zrozumieć (z tych samych powodów), ale z drugiej strony zdaje się, że w niektórych miejscach coś z tego zostało do dzisiaj: https://kobieta.wp.pl/zmuszane-do-bycia-grubymi-dramat-kobiet-w-mauretanii-5983071665504897g. Może wtedy też wyprodukowanie takiej "laski" wymagało dużo pracy/wysiłku? W sumie Chinka ze zdeformowanymi stopami też była mniej przydatna pod względem powiedzmy praktycznym czy też utylitarnym, a jednak je "wytwarzano".
  7. Grunt, że KW ma (jakiekolwiek) przychody na swoje działanie.
  8. W języku maszynowym się nie da Ale w językach wyższego poziomu, powiedzmy C/C++ czy C# lub Java to już inna sprawa:) Dla mnie nie, chociaż używam ich w sensie potocznym, nie trzymam się ścisłych definicji. Ale automat skończony to dla mnie coś co przetwarza dane używając stałej (z grubsza) pamięci, przełączając się między kilkoma/kilkunastoma/kilkudziesięcioma stanami. Parser nie jest w moim odczuciu automatem skończonym, bo używana przez niego pamięć (zazwyczaj) rośnie wraz z ilością przetworzonego tekstu. Kalkulator RPN od Kernighana i Ritchiego też nie jest automatem skończonym, bo stos może urosnąć do dowolnie dużego rozmiaru przy dostatecznie długim i spełniającym odpowiednie warunki inpucie. Gdyby produkował wynik z wykorzystaniem stosu o stałym rozmiarze, nazwałbym go automatem skończonym (niezależnie od tego, że to tylko moje subiektywne odczucia). Zwłaszcza Pythonowcy podobno chętnie używają wyjątków. W przypadku C# i Javy jest coś, co mnie zniechęciło częstego do używania wyjątków (jakieś wrażenie, że po powrocie do kodu po dłuższym czasie będzie trudno się połapać, gdzie i po co jest rzucany wyjątek), możliwe, że w Pythonie jakiś szczegół jest inaczej rozwiązany. Mam małe doświadczenie z Pythonem, czasem piszę sobie jakieś max. kilkudziesięciolinijkowe skrypty, które coś mi ułatwiają.
  9. Tylko że w językach statycznie typowanych od znajdowania błędów programisty (zwłaszcza takich prostych, dokładniej mówiąc prostych dla komputera, nie dla ludzia) jest kompilator. W praktyce sytuacje, gdy chcemy używać nulla są dość rzadkie, języki programowania powinny przyjmować, że jeśli programista nie zaznaczy jawnie inaczej, dana wartość/zmienna itp. nie przyjmuje wartości null. Java i wiele innych języków programowania zostały zaprojektowane z odwrotnym założeniem. Automatów skończonych jakoś nigdy nie musiałem pisać na produkcji, ale parsery pisałem wiele razy i jak dla mnie, z punktu widzenia programisty, najwygodniejsza jest wtedy instrukcja switch/case, wsadzona w pętlę. Tak jak to już dawno temu zrobili Kernighan i Ritchie: https://clc-wiki.net/wiki/K&R2_solutions:Ancillary:Polish_calculator W przypadku parsera (automatu skończonego pewnie tak samo, nie widzę powodu, żeby miało być inaczej) bardzo ważne jest przygotowanie sobie w głowie listy wszystkich możliwych stanów (albo zasad konstruowania poprawnych wartości, jeśli np. parser ma postać funkcji zwracającej AST) i pisanie kodu dla każdego przypadku w taki sposób, żeby nie wyprowadzał stanu (lub wartości) poza te dopuszczalne możliwości. Więc switch pasuje do tego jak ulał. Ewentualnie można dyskutować, że goto sprawiłoby, że wygenerowany kod wykonywałby się ociupinkę szybciej (nie orientuję się, na ile dobrze kompilator potrafi zoptymalizować pętlę ze switchem wewnątrz), ale w praktyce b. rzadko występują sytuacje, gdy taka optymalizacja byłaby na tyle istotna, żeby specjalnie pisać kod pod kątem takiej optymalizacji.
  10. Powszechnie wiadomo, że komentarzy nikt nie czyta Sam wiele razy widziałem w kodzie komentarz od dawna nieaktualny, bo kod, którego dotyczył, był potem wiele razy zmieniany. Powiem więcej, wiele razy pozostawiałem - z całą premedytacją i zupełnie się tego nie wstydzę, taki ze mnie niecnota - ten zdezaktualizowany komentarz niezmieniony. A to dlatego, że komentarz nie dotyczył linijki kodu, którą zmieniałem (tylko np. linijki powyżej), a te kilka-kilkanaście modyfikacji, które przede mną robili inni programiści, sprawiało, że opisywana część kodu była o wiele bardziej skomplikowana niż początkowo, więc komentarz musiałby być teraz bardzo zaktualizowany do bardzo skomplikowanego wielolinijkowego opisu odzwierciedlającego nową złożoność i... niby czemu ja miałbym wykonywać tę pracę, skoro nie wiąże się z poprawkami, które ja wprowadzałem? Widziałem parę miesięcy temu fajny artykuł o historii Cobola: https://logicmag.io/care/built-to-last/ Nie wiem ile w nim prawdy, a ile to ideologia (chwilami budzą się wątpliwości przy czytaniu), ale podważa parę mitów, chociażby daje do myślenia w kwestii roli kobiet w historii informatyki i dowcipów o "świnkach morskich". Zresztą, jeśli Cobol nie miał null-a (nie wiem czy nie miał, nie znam Cobola, ale zaczynałem od ZX Spectrum Basic*), języka, w którym nie było null-a), to niewykluczone, że da się dyskutować, czy na pewno dużo gorszy od np. Javy. *) jeśli ktoś ma wątpliwości, to nie, Basic mnie nie zepsuł, nie używam goto, ani nigdy nie odczuwałem potrzeby używania go (poza Basicami na 8-bitowe komputery, gdzie nie było wyboru).
  11. Też mam ten problem i też często pisałem kod "bez else", zwłaszcza dawniej, tylko że wtedy właśnie wolałem wyjść przez return itp.
  12. Skoro już offtopikujemy: ale wychodzisz wcześniej przez yield/return/break? Czy też może i tego nie używasz? ;)
  13. To jak u mnie na wsi - dom na niewielkim wzniesieniu, a ma założone dreny, żeby woda odpływała z piwnicy.
  14. Dla ścisłości: łączenie się postaw ekologicznych z lewą stroną sceny politycznej to stosunkowo nowe zjawisko, dawniej to właśnie konserwatyści dość często przyjmowali postawy "eko", http://www.zb.eco.pl/zb/45/dwornik.htm
  15. Tu dalej IMHO pozostaje otwarta kwestia, czy sztuczne/odgórne pobudzanie jest pożyteczne (czy przynosi jakieś korzyści). Ja jak już pisałem, nie bardzo w to wierzę. Po drugie: vs. Ale zdajemy się na "mądrość" tylko tych wybranych konsumentów, którym poprzednio zwiększyliśmy siłę nabywczą (p. poprzednie zdanie). Czyli znów odgórne decydowanie - które podmioty wybrać, żeby one odstały te dodrukowane pieniądze. Jakoś nie słyszałem, żeby w którymkolwiek kraju władza ogłosiła w telewizji: "Ludzie, słuchajcie, jutro możecie sobie legalnie wydrukować pięć banknotów 100 złotowych/dolarowych/etc na osobę (zależnie jaka obowiązuje waluta w danym kraju)." :P Z inflacją dolara mieli niewątpliwie. Dlatego uważam za pożądaną sytuację, w której są łatwo dostępne metody oszczędzania odporne na inflację. Natomiast spadek wartości dolara w stosunku do złotówki (czy też raczej wzrost złotówki w stos. do dolara) był dla nich korzystny - po upadku komunizmu mogli oszczędzać więcej niż jednego dolara miesięcznie. Gdyby całe życie oszczędzali 1 dolar/mies. uzbieraliby ledwie kilkaset dolarów, co by pewnie starczyło na 1-2 dniową wycieczkę. A w rzeczywistości wyjechali na kilka miesięcy (mają przyjaciela w USA, u którego mogli mieszkać). Dolary nie były dla nich celem, celem była wyprawa do USA, a dolary były tylko środkiem.
×
×
  • Create New...