Programista vs AI

[VisualLab]

Dnia 4.04.2026 o 01:56, H1M4W4R1 napisał:

Python nie jest złą technologią... wprawdzie jest zasobożerny, ale do szybkich testów jest znacznie lepszy niż C czy C#, gdzie program pisałbyś 5x dłużej  

Polemizowałbym  A w zasadzie dlaczego nie spróbować...

Niestety, zasobożerność to nie jest jedyny grzeszek Pythona. To jest cały zestaw: powolność działania skryptów (jak melasa), brak systemu typów (typy są tylko wewnątrz interpretera) a co za tym idzie brak deklaracji zmiennych i ich automatyczne przepoczwarzanie się (raz liczba, a potem ciąg znaków), brak stałych, brak hermetyzacji „klas” (dysponuje on jedynie naiwnym „wyrobem obiektopodobnym”), białe znaki zamiast symboli początku i końca bloku, problemy z wdrożeniem „aplikacji pythonowej (a ściślej : zbioru skryptów) z powodu różnych wersji „bibliotek pythonowych”, co wymusza konieczność używania obejść w postaci kontenerów (lub ręcznego rozwiązywania tego bałaganu) i nie mam tu na na myśli różnic pomiędzy wersjami Pythona 2 i 3. A to tylko te najbardziej dotkliwe uciążliwości, ale nie jedyne.

Oczywiście nie ma problemu, gdy ktoś tworzy zestaw skryptów na swoje potrzeby. Problem pojawia się wtedy, gdy ktoś upublicznia taki projekt, bo inni ludzie często naiwnie sądzą (ci co niewiele wiedzą o Pythonie), że to program jak każdy inny. Jeśli to prosty projekt, to być może użytkownicy nie trafią na kłopoty. Ale nie zawsze tak jest (np. pythonowe wyroby "naukowe" stosowane w chemii czy biologii z różnym skutkiem).

Druga kwestia to kłamliwe blogi i „artykuły” w mediach, jakoby w Pythonie można było stworzyć program tak, jak w każdym innym języku programowania. Tylko łatwiej i szybciej. Zupełnie jak w tych click-bait’owych (patologicznych) reklamach: „Odkrył ten jeden dziwny trik. Zawodowi specjaliści go nienawidzą.” (za specjaliści można wstawić dowolne zawody: lekarze , mechanicy, programiści, księgowi, itd.). Tymczasem to jest oszustwo, bo nie ma drogi na skróty. Kiedy taki adept pythonowy próbuje się wziąć za kolejny język programowania, to zaczyna się narzekanie, lamenty, psioczenie że jest ciężko, że język X, Y czy Z „jest do d…, a Python to ho, ho, ho – sam krawaty wiąże i usuwa ciąże”. A problemem jest to, że nabrali fatalnych nawyków ucząc się jako pierwszego niedopracowanego języka skryptowego (podobnie bywa z JS). Tacy ludzie często nie chcą się przyznać, że zmarnowali czas. Próbują to sobie racjonalizować (a to są tylko błędy poznawcze).

Ale pal licho media i blogi, wszak „w Internecie pisać każdy może, trochę lepiej lub gorzej”. Prawdziwą plagą jest forsowanie nauki Pythona na kierunkach informatycznych na uczelniach, jako pierwszego języka programowania.

Co do tworzenia prototypów – jak ktoś tak chce, to jego sprawa. Jak robię prototyp w docelowym języku to go potem łatwo poprawić, rozbudować, zmodyfikować. Bo to nadal ten sam język. A tak, to trzeba przepisywać, tłumaczyć "z pytoniego na nasze". I to wcale nie 1:1. Mnie by się nie chciało. No ale kto bogatemu zabroni?  

Dnia 4.04.2026 o 01:56, H1M4W4R1 napisał:

Wolność człowieka kończy się w miejscu, w którym zaczyna się wolność innego człowieka.

Całkowicie się zgadzam. W tej dywagacji miałem na myśli to, że pod płaszczykiem rozwoju IT (tu: AI) różni cwaniacy korporacyjni „wespół-wzespół” z politykami (raczej mniej-cwani) będą próbować nadużywać infrastrukturę krajową na swoje potrzeby w imię konieczności rozwoju AI („no bo inni już to mają, to my też musimy mieć”). A koszty jak zwykle będą próbowali przerzucić na podatników (czyli m.in. nas) na zasadzie: "Wicie-rozumicie towarzysze" i "Rodacy pomożecie? No, pomożecie" - że zacytuję 2 razy klasyka

Dnia 4.04.2026 o 01:56, H1M4W4R1 napisał:

Idealnie nigdy nie będzie, ale przynajmniej mogliby się starać nie rozwalać całej planety i gospodarki w zatrważającym tempie... W każdym razie pozostaje nam liczyć, że nie doczekamy do czasów jak nie będzie można siać własnych nasion (bez opatentowanych genów), czy mieszkać we własnym domu z niskimi kosztami... Chociaż Polak sobie zawsze poradzi  

Tak, też się z tym zgadzam. Niestety politycy w większości są leniwi, chciwi (a niektórzy jeszcze dodatkowo głupi). A czy Polak sobie poradzi? Może lepiej żeby zaczął sobie radzić zawczasu (np. teraz), zanim zacznie być tak źle, że nic nie da się zrobić (a jak nas uczy historia czasem nie ma jak uciec od zła, np. w 1939, a potem 1945). Te ostatnie kilka (a może nawet kilkanaście) lat „wysoków” polityków z różnych stron świata dobitnie pokazują, że im się znudził spokój i równowaga (to stopniowo narastało). W każdym większym kraju jest jakiś świr, bandzior albo menda która razem ze swoją ekipą „kołysze łajbą świata coraz mocniej, coby ją wywrócić”. W "naszym euro-kołchozie" też mają różne "ciekawe" pomysły, ale "chińczyki trzymają się mocno", więc może wierchuszka UE poluzuje nieco "grüne Schraube".

Dnia 4.04.2026 o 08:35, orb777 napisał:

Jednym z głównych założeń pythona nie jest szybkość, tylko przenośność. Java również nie należała do demonów wydajności, a czemuś z powodzeniem opanowała warstwę aplikacji w androidzie, systemie, który ma większość rynku mobilków.

Ale to była po prostu odgórna decyzja „białych kołnierzyków” z Google. I to wtedy (n lat temu), bo teraz to pewnie wybraliby jakiś inny język (być może Go). W zasadzie Androidowi po cholerę przenośność, jak i tak w smartfonach są używane SoC ARM. Sam Android jest nadzorowany tylko przez jedną firmę – ich, czyli Google. A zarząd Apple i tak zrobi wszystko, żeby uprzykrzyć życie „poganiaczom niewolników” z Google. Więc ta "javn'a" przenośność to na cholerę się zdała. Wybraliby coś kompilowanego do kodu maszynowego, to przynajmniej Android były wtedy nieco żwawszy i mniej żarłoczny na RAM i czas CPU (a w konsekwencji na energię). A tak - to jest taka informatyczna pokraka.

[H1M4W4R1]

1 godzinę temu, VisualLab napisał:

To jest cały zestaw: powolność działania skryptów (jak melasa)

Czyli zasobożerność  

1 godzinę temu, VisualLab napisał:

brak systemu typów (typy są tylko wewnątrz interpretera)

Nie tylko. Chyba nie pisałeś nigdy w Pythonie...

1 godzinę temu, VisualLab napisał:

białe znaki zamiast symboli początku i końca bloku

To tak samo jak ktoś mógłby się przyczepić, że C używa klamr zamiast "end" znanego z LUA

1 godzinę temu, VisualLab napisał:

Jeśli to prosty projekt, to być może użytkownicy nie trafią na kłopoty. Ale nie zawsze tak jest (np. pythonowe wyroby "naukowe" stosowane w chemii czy biologii z różnym skutkiem).

Od tego jest requirements.txt oraz wirtualne środowiska... Ale fakt, to jest uciążliwe (chociaż wychodzi na to samo jak pakujesz większość bibliotek do aplikacji C#).

1 godzinę temu, VisualLab napisał:

Jak robię prototyp w docelowym języku to go potem łatwo poprawić, rozbudować, zmodyfikować. Bo to nadal ten sam język.

W tych czasach to żaden argument. LLM spokojnie to przepisze między różnymi językami, a nawet biblioteki dobierze odpowiednie.

1 godzinę temu, VisualLab napisał:

Ale to była po prostu odgórna decyzja „białych kołnierzyków” z Google. I to wtedy (n lat temu), bo teraz to pewnie wybraliby jakiś inny język (być może Go).

Android już od długiego czasu nie używa Javy tylko Kotlina  

A Java została wybrana ze względu na to, że już była stosowana wcześniej (Symbian itp.), ponieważ wiele producentów używało różnych procesorów w swoich urządzeniach, a co za tym idzie potrzebny był interpreter, który ogarnie tłumaczenie instrukcji.

1 godzinę temu, VisualLab napisał:

W zasadzie Androidowi po cholerę przenośność, jak i tak w smartfonach są używane SoC ARM.

To, że są nie znaczy, że będą  (już teraz RISC-V zyskuje na popularności).

[orb777]

7 godzin temu, VisualLab napisał:

Ale to była po prostu odgórna decyzja „białych kołnierzyków” z Google. I to wtedy (n lat temu), bo teraz to pewnie wybraliby jakiś inny język (być może Go). W zasadzie Androidowi po cholerę przenośność, jak i tak w smartfonach są używane SoC ARM. Sam Android jest nadzorowany tylko przez jedną firmę – ich, czyli Google. A zarząd Apple i tak zrobi wszystko, żeby uprzykrzyć życie „poganiaczom niewolników” z Google. Więc ta "javn'a" przenośność to na cholerę się zdała. Wybraliby coś kompilowanego do kodu maszynowego, to przynajmniej Android były wtedy nieco żwawszy i mniej żarłoczny na RAM i czas CPU (a w konsekwencji na energię). A tak - to jest taka informatyczna pokraka.

Bardziej miałem na myśli przenośność pythona. Nie wszystko było idealne, a mimo to zaistniało na rynku i człowiek z tego korzysta. W świecie idealnym nie ma chorób, głodu, wojen, javy i pythona, bo nie ma też ludzi.

[VisualLab]

Hmm, brak wygodnej obsługi wielopoziomowego cytowania trochę utrudnia odpisywanie.

10 godzin temu, H1M4W4R1 napisał:

12 godzin temu, VisualLab napisał:

brak systemu typów (typy są tylko wewnątrz interpretera)

Nie tylko. Chyba nie pisałeś nigdy w Pythonie...

Nie zrozumieliśmy się. To co ma Python to jest bardzo skromna (wręcz szczątkowa) namiastka. To, że da się w kodzie wstawić instrukcję sprawdzającą typ zmiennej czy wymuszać interpretację (namiastka rzutowania) to za mało, żeby mówić o systemie typów. Bo skutek tego sprawdzenia może pojawi się dopiero w czasie wykonania (albo i nie). Z kolei adnotacje to tylko tekst. W klasycznych językach kompilowanych do kodu maszynowego (Ada, C, C++, Fortran, Pascal, Rust, itd.) czy bajtowego (C#, Java, itd.) kompilatory robią z tego konkretny użytek. To jest prawdziwy system typów (statyczny system typów). Czasem ktoś pisze, że Python ma dynamiczny system typów. Ale to też jest nieścisłe (chociaż częściowo prawdziwe). Bo to dałoby się zrobić i w tych wymienionych językach przez użycie typu wariantowego dla każdej zmiennej(1). Skutek byłby podobny do tego w Pythonie. Docelowy program byłby powolny w działaniu i żarłoczny na RAM. W każdym razie brak konieczności jawnego określania typów dla zmiennych w skryptach Pythona (i ich zgadywanie przez interpreter) zdaje się jest bardzo lubiany przez osoby go używające. To jest chyba część jego "magii". Ale ta "magia" kosztuje. Jednym użytkownikom Pythona "to zwisa" a inni o tym po prostu nie wiedzą. 

(1) To oczywiście działanie trochę na siłę, mało użyteczne. Raczej pokazywałoby tylko, że technicznie jest to wykonalne. Dlatego typ wariantowy jest używany tylko w niektórych przypadkach.

10 godzin temu, H1M4W4R1 napisał:

12 godzin temu, VisualLab napisał:

białe znaki zamiast symboli początku i końca bloku

To tak samo jak ktoś mógłby się przyczepić, że C używa klamr zamiast "end" znanego z LUA

Niby tak. Jest jednak takie "ale", że białe znaki są mało czytelne. Gdyby to był jeden znak (spacja) to jeszcze pół biedy. Tymczasem ogranicznikiem są wcięcia. A te mogą się składać z kilku białych znaków (i co gorsza można je mieszać). W przypadku klasycznych języków są klamry albo słowa kluczowe, ale po jednym egzemplarzu. Również brak znacznika końca (albo separatora) instrukcji (tj. średnika) to też zły pomysł. Twórcy starych języków programowania (C, Fortran, Pascal) byli tego świadomi. Niestety Guido, gdy tworzył Pythona, był w wieku "młodych i gniewnych". I dał się ponieść "młodzieńczemu buntowi" przeciwko "skostniałym konwenansom" głoszonym przez "starych pryków informatyki". Ale to te stare pryki miały rację, co ujawniło się po latach. Niestety, stopniowa poprawa (naprawa) języka Python nie nastąpiła (a powinna). A teraz jest za późno, bo "magia" przestałaby działać.

Oczywiście można pokazać przykład (podstępny i złośliwy), gdzie jawnie wpisany znak końca instrukcji powoduje zatrzymanie pracy kompilatora i zgłoszenie błędu. Dobrym przykładem jest kod prostego programu konsolowego składający się z kilkunastu linijek w C++, gdzie kompilator zatrzymuje się gdzieś w środku kodu i twierdzi, że trafił na błąd. Z komunikatu wynika, że problemem jest średnik w jednej z linii. Wskazany średnik niczym nie różni się od reszty średników(2). Tylko, że kompilator "widzi" kod znaku a nie jego kształt graficzny. Ten kod to 0x037E (znak geckiego cytatu), a tymczasem zwykły średnik ma kod 0x003B. Niestety człowiek kieruje się tylko wyglądem znaku. Zaawansowane edytory oczywiście mogą pokazać informacje o kodach znaków. Ale nie sposób przeglądać każdy znak w kodzie albo kazać wyszukiwać edytorowi podejrzane znaki. Tylko że w tym złośliwym przykładzie trzeba celowo podmienić określony znak, żeby doszło do zamieszania.

(2) Można to łatwo sprawdzić na zrzucie ekranowym, powiększonym w edytorze graficznym.

10 godzin temu, H1M4W4R1 napisał:

12 godzin temu, VisualLab napisał:

Jak robię prototyp w docelowym języku to go potem łatwo poprawić, rozbudować, zmodyfikować. Bo to nadal ten sam język.

W tych czasach to żaden argument. LLM spokojnie to przepisze między różnymi językami, a nawet biblioteki dobierze odpowiednie.

Tak, ale to od niedawna. Od 2, 3 może 4 lat. I te rozwiązania dopiero raczkują. Oczywiście za jakiś czas (parę lat) zostaną dopracowane. I mam nadzieję, że będą dostępne dla szerszego ogółu, a nie jako typowy korporacyjny SaaS (2). A wtedy to LLM "zrobi co trzeba" w prawie każdym języku programowania. I nie trzeba będzie pisać prototypów skryptowych  Bardzo by to przyspieszyło i ułatwiło programowanie. W takiej sytuacji deklarowanie zmiennych razem z typami jak (i inne pozorne trudności) odejdą w niebyt

(2) Przykład korpo-usługi: jedyne 35$ abonamentu za miesiąc dla 1 osoby niezależnie od tego przez ile godzin ktoś korzysta, jak w przypadku oprogramowania Adobe.

10 godzin temu, H1M4W4R1 napisał:

Android już od długiego czasu nie używa Javy tylko Kotlina  

A Java została wybrana ze względu na to, że już była stosowana wcześniej (Symbian itp.), ponieważ wiele producentów używało różnych procesorów w swoich urządzeniach, a co za tym idzie potrzebny był interpreter, który ogarnie tłumaczenie instrukcji.

Tak, ale w czasie powstawania Androida, "ten" Kotlin chyba jeszcze nie istniał. Dlatego wybrali Javę. Znaczy, wcześniej istniały tylko 2 Kotliny: ten od keczupu (polski) i ten koło Sankt Petersburga (ruski). Trzeci powstał potem, też ruski  Nazwany na cześć tego drugiego (czyli wyspy).

10 godzin temu, H1M4W4R1 napisał:

12 godzin temu, VisualLab napisał:

W zasadzie Androidowi po cholerę przenośność, jak i tak w smartfonach są używane SoC ARM.

To, że są nie znaczy, że będą  (już teraz RISC-V zyskuje na popularności).

Ale czy tego nie powinien załatwiać OS? Przecież i tak jądro jest napisane w C (wszak to stare, zmodyfikowane jądro Linux'a). A część pozostałych wnętrzności OS'a napisana pewnie w C++. Java była pomyślana dla twórców oprogramowania instalowanego w systemie.

[kroszkanorber]

Moje doświadczenia z SI są podobne — potrafi pisać to, co użytkownik chce usłyszeć, ale często nie widzi szerszego kontekstu.

Przy pracy z C++ miałem podobnie: żeby kod działał spójnie, musiałem przejąć pełną kontrolę nad architekturą, bo SI nie była w stanie przewidzieć zależności między plikami.

Dlatego traktuję SI jako narzędzie pomocnicze — przydatne, ale tylko wtedy, gdy ma się wystarczającą wiedzę, żeby weryfikować odpowiedzi.

W przeciwnym razie faktycznie można się łatwo pogubić.
Nie korzystam z wersji płatnych i może to wpływać na ograniczenia.

[bjrk]

11 godzin temu, kroszkanorber napisał:

Nie korzystam z wersji płatnych i może to wpływać na ograniczenia.

Używam wersji płatnych, bo te bezpłatne zbyt szybko mi się wyczerpywały, ale wniosek jest taki sam. Trzeba dokładnie wiedzieć co się chce i pilnować, aby nie było zgadywania i odpływania. Wtedy może być bardzo przydatne. 
Przy okazji. Rozwój jest bardzo szybki, w ciągu kilku miesięcy widzę istotne zmiany.

[VisualLab]

12 godzin temu, bjrk napisał:

Używam wersji płatnych, bo te bezpłatne zbyt szybko mi się wyczerpywały, ale wniosek jest taki sam. Trzeba dokładnie wiedzieć co się chce i pilnować, aby nie było zgadywania i odpływania. Wtedy może być bardzo przydatne. 
Przy okazji. Rozwój jest bardzo szybki, w ciągu kilku miesięcy widzę istotne zmiany.

Czyli zasada prawie taka sama jak przy przeszukiwaniu dużych baz informacji. Im bardziej szczegółowe zapytanie, tym bardziej precyzyjna odpowiedź. Z jedną różnicą - jak w bazie danych nie ma pewnych informacji, to wynikiem jest zbiór pusty (innymi słowy odpowiedź w stylu: "nie mam tego czego szukasz"). Tymczasem w przypadku "czatów ejajowych" jakiś wynik jest zawsze. Jakiś - czasem sensowny a czasem bzdurny. Jak się ma wiedzę, to odpowiedź można łatwo zweryfikować. A jak się jej nie ma, to pozostaje albo założyć, że "ejaj" pisze prawdę (czyli ślepa wiara - jest to głupie postępowanie) albo spróbować to poszukać (sprawdzić) innym sposobem. W obu przypadkach (tj. zarówno posiadania jak i braku wiedzy) użycie "ejaja" nie ma sensu, jest marnowaniem czasu. Bo jak się wie, to po cholerę "przepychać tekst przez sieć tam i nazad". A jak się nie ma pewności, że odpowiedź jest prawidłowa, to lepiej było ten czas poświęcić na przeglądanie podręczników lub baz wiedzy. Zatem wniosek jest taki: żeby "ejaj" był użyteczną usługą musi:

1. być nakarmiony danymi, które mają jasno sprecyzowane metadane: prawda lub fałsz, lub

2. mieć wbudowany weryfikator poprawności (prawdziwości, rzetelności) wyszukiwanych i agregowanych treści.

A tymczasem "ejaje" były "karmione" treścią zgarniętą z Internetu jak leci. Bez sortowania, weryfikowania, opisywania. To tak, jakby ktoś przygotowujący jedzenie, zgarnął do kotła wszystko co leży na stole (jedzenie różnego rodzaju, odpadki, okruchy, sztućce, opakowania, itd.) i z tego ugotował zupę.

Z drugiej strony jak się chciało wytrenować sieć na dużej ilości danych, to kto miałby te petabajty danych sortować, weryfikować i opisywać? Ilu ludzi trzeba by do tego zatrudnić? I to ludzi mających wiedzę. Toż żadnej z tych bogatych korporacji nie stać na zatrudnienie takich ludzi (i w takich ilościach) do tego zadania. I ile to by trwało? 20 lat? Z drugiej strony liczenie na to, że: "z czasem wszystko jakoś się ułoży" jest kretyńskie. Nic się samo nie ułoży. Przynajmniej nie informacje. Wszelka użyteczna wiedza jaką ludzie wytworzyli, to wynik mozolnej, mrówczej pracy wielu pokoleń ogromnej rzeszy ludzi. Z drugiej strony jak dane zostaną przygotowane przez speców (ekspertów) to wynik trenowania sieci jest niezwykle udany. Przykładem jest AlphaFold.

Wniosek – żeby "ejaj" był użyteczny najpierw ludzie muszą przygotować bazę wiedzy - rzetelnie, bez próby oszukiwania, obchodzenia czy "szpachlowania" problemu wiarygodności danych. Nie ma drogi na skróty. W przeciwnym razie media dalej będą pisać brednie o halucynacji AI. Nie ma żadnych halucynacji - są tylko błędy i braki w algorytmach oraz brak rzetelnie przygotowanych baz danych. Mrzonki o ogólnej AI to naiwny sen głupków z zarządów korporacji, które to głupki liczyły na szybkie zgarnianie kasy (i kretyni zwani inwestorami, co dali im pieniądze). A tymczasem na razie nie wyszło, a przynajmniej nie tak, jak "białe kołnierzyki" liczyły (a liczyły na liczenie spływającej grubej kasy od klientów).

Obecnie furorę robią generatory obrazków, które tworzą portrety ludzi o dwóch głowach (te gorsze "ejaje") albo o siedmiu palcach lewej ręki (te lepsze "ejaje"). Albo takie, co generują "ilustracje" elektroniczne, które bardziej przypominają zapieczony makaron na desce niż PCB z przylutowanymi elementami. Albo sklejacze cudzych tekstów. A gdzie prawa autorskie? Kiedy Google, Microsoft (czy jakieś inne korpo) żerują na cudzej własności intelektualnej ("no bo AI" potrzebuje danych), to nagle gęganie o prawach autorskich ucichło. Doczekać się nie mogę aż ta p…a bańka pęknie. Bo jak pęknie, to korporacje i inwestorzy stracą pieniądze i odechce się im „pompować hajp ejajowego” bubla. I rozwojem AI zajmą się tylko ci, to chcą zrobić z tego użyteczne narzędzie.

Edytowano 13 kwietnia przez VisualLab

[H1M4W4R1]

1 godzinę temu, VisualLab napisał:

mieć wbudowany weryfikator poprawności (prawdziwości, rzetelności) wyszukiwanych i agregowanych treści.

Uhm... ale współczesne modele już to potrafią. Wystarczy im powidzieć, że mają podać źródła (linki) oraz zweryfikować zgodność informacji w kilku źródłach. Claude, którego używam bez problemu cytuje artykuły z Wikipedii i o ile Wiki zawsze była wyśmiewana jako średnio-rzetelne źródło informacji tak wbrew pozorom mają całkiem dobrą moderację treści (podobnie jak ScienceMadness).

AI najgorzej radziło sobie z matematyką i "liczeniem znaków", ale to też już zostało rozwiązane poprzez umiejętności i MCP - AI może stworzyć skrypt Pythona/Basha i go uruchomić by zagwarantować prawidłowe wyniki obliczeń.

1 godzinę temu, VisualLab napisał:

Wniosek – żeby "ejaj" był użyteczny najpierw ludzie muszą przygotować bazę wiedzy - rzetelnie, bez próby oszukiwania, obchodzenia czy "szpachlowania" problemu wiarygodności danych.

Baza bez błędów nie istnieje  Zawsze jakieś będą, bo jednak nasza nauka cały czas idzie do przodu i niektóre ustalenia się zmieniają.

1 godzinę temu, VisualLab napisał:

W przeciwnym razie media dalej będą pisać brednie o halucynacji AI. Nie ma żadnych halucynacji - są tylko błędy i braki w algorytmach oraz brak rzetelnie przygotowanych baz danych.

To nie są błędy w algorytmach. Jak to kolega @ethanak powiada: problem siedzi zawsze przed monitorem. I w pełni się zgadzam z Jego twierdzeniem. Jak tworzę programy czy używam AI to zawsze źródłem problemu jest człowiek.

1 godzinę temu, VisualLab napisał:

Obecnie furorę robią generatory obrazków, które tworzą portrety ludzi o dwóch głowach (te gorsze "ejaje") albo o siedmiu palcach lewej ręki (te lepsze "ejaje").

Ostatnio im się dość mocno poprawiło  Szczególnie jak używa się odpowiednich filtrów (Embedding, Lora) do generacji. Osobiście też uważam to za slop, ale do prototypowania jak najbardziej się nadaje.

1 godzinę temu, VisualLab napisał:

Albo takie, co generują "ilustracje" elektroniczne, które bardziej przypominają zapieczony makaron na desce niż PCB z przylutowanymi elementami.

Bo żadne z tych generatorów obrazków nie są dostosowane do generowania schematów. To tak jakbyś chciał upiec ciasto wrzucając składniki do miski i ich nie mieszając. Efekt byłby podobny.

Prawidłowym podejściem jest zdefiniowanie formatu zapisu schematu w formie tekstowej i użycie kilku agentów LLM do budowy schematu oraz przeszukiwania internetu w poszukiwaniu niezbędnych informacji, by stworzyć konkretny projekt. Niestety problem leży w tym, że większość schematów dostępna jest w formatach obrazowych, a nie tekstowych. To powoduje gigantyczne problemy z dostępnością materiału źródłowego do tego zadania, a firmy od edytorów PCB mocno angażują się w projektowanie własnych, dedykowanych rozwiązań.

[kroszkanorber]

22 godziny temu, VisualLab napisał:

Mrzonki o ogólnej AI to naiwny sen głupków z zarządów korporacji, które to głupki liczyły na szybkie zgarnianie kasy (i kretyni zwani inwestorami, co dali im pieniądze). A tymczasem na razie nie wyszło, a przynajmniej nie tak, jak "białe kołnierzyki" liczyły (a liczyły na liczenie spływającej grubej kasy od klientów)

Zastanawiające jest to, że jednak dużo zostało zainwestowane w niepewną przyszłość. Zgadzam się, że na razie wygląda to tak jakby dziecku dać zabawkę. Pozostaje czekać, aż dorośnie.

Brakuje bazy błędów. Moim zdaniem człowiek się uczy przez wyniki własnego postępowania. Ale czy można to zaimplementować technicznie (dużo danych i interpretacji). Myślę, że SI to baza danych i szybko się ten stan nie zmieni.

Dla mnie SI jest najwygodniejszą wyszukiwarką mimo niedoskonałości. Potrafi szybko analizować tekst i coraz częściej trafnie interpretuje. Progres jest widoczny. Świadomość tego, że korzystamy z narzędzia jest wystarczająca by było pożyteczne.

[VisualLab]

Dnia 13.04.2026 o 23:34, H1M4W4R1 napisał:

Dnia 13.04.2026 o 21:58, VisualLab napisał:

mieć wbudowany weryfikator poprawności (prawdziwości, rzetelności) wyszukiwanych i agregowanych treści.

Uhm... ale współczesne modele już to potrafią. Wystarczy im powidzieć, że mają podać źródła (linki) oraz zweryfikować zgodność informacji w kilku źródłach. Claude, którego używam bez problemu cytuje artykuły z Wikipedii i o ile Wiki zawsze była wyśmiewana jako średnio-rzetelne źródło informacji tak wbrew pozorom mają całkiem dobrą moderację treści (podobnie jak ScienceMadness).

To powinno być standardem w zwracaniu wyników przez AI, bez specjalnego dopraszania się o źródło.

Co do Wikipedii, to... hmm... Mam zastrzeżenia. Ta opinia na temat słabej wiarygodności Wikipedii nie wzięła się znikąd. W dziedzinach społecznych (ekonomia, politologia, socjologia, historia) można sprawdzić ile było ciągłych zmian wykonywanych tam i nazad. Gorzej, że różne bzdury trafiały się się w tematach informatycznych, która to dziedzina z polityką nie ma nic wspólnego. I bywało, że po usunięciu błędów, jakiś uparty troll "poprawiał" treść artykułu zgodnie ze swoim widzimisię (w zależności czy coś uwielbiał lub nienawidził). Najbardziej kontrowersyjne tematy z informatyki dotyczą: (1) architektury Linux'a i (2) języków programowania. Sam czasem prostowałem błędy czy niejasności w niektórych artykułach. Ale do tego trzeba mieć dużo czasu i niesamowitą cierpliwość. A ja nie mam ochoty użerać się z trollami. Jeśli potrzebuję uzupełnić wiedzę, to osobiście wolę zajrzeć do książki albo do jakiejś publikacji.

Dnia 13.04.2026 o 23:34, H1M4W4R1 napisał:

AI najgorzej radziło sobie z matematyką i "liczeniem znaków", ale to też już zostało rozwiązane poprzez umiejętności i MCP - AI może stworzyć skrypt Pythona/Basha i go uruchomić by zagwarantować prawidłowe wyniki obliczeń.

Co do matematyki, to lepiej będzie, jeśli wszelakie mniej i bardziej zaawansowane obliczenia będą wykonywać programy CAS (Maple, Mathcad, Mathematica) czy środowiska obliczeniowe (Matlab, Scilab), które są do tego całkiem nieźle przystosowane. Ponadto WolframAlpha działa już dość długo i to całkiem nieźle. Jego darmowa wersja jest w zupełności wystarczająca dla uczniów, studentów i hobbystów. Zresztą obecne arkusze kalkulacyjne też nieźle sobie radzą z prostymi obliczeniami. A jak ktoś ma naprawdę duże wymagania, to AI mu nie pomoże. Bo do różnorakich zastosowań dziedzinowych typu modelowanie czy symulacje to i tak trzeba użyć wyspecjalizowanego narzędzia (jakieś Chemcady, Solidworksy, Gaussian'y, itd.).

Dnia 13.04.2026 o 23:34, H1M4W4R1 napisał:

Dnia 13.04.2026 o 21:58, VisualLab napisał:

Wniosek – żeby "ejaj" był użyteczny najpierw ludzie muszą przygotować bazę wiedzy - rzetelnie, bez próby oszukiwania, obchodzenia czy "szpachlowania" problemu wiarygodności danych.

Baza bez błędów nie istnieje  Zawsze jakieś będą, bo jednak nasza nauka cały czas idzie do przodu i niektóre ustalenia się zmieniają.

Tak. Chociaż nieścisłości z powodu określonego stanu nauki są chyba mniej dotkliwe niż błędy i fałsze (często celowe), które wkradają się w publikacje naukowe. Zwykle motorem działania takich oszustów jest chęć przyspieszenia kariery naukowej (a czasem też zdobycie sławy). Z nauk przyrodniczych to najczęściej chyba dotyczy to biologii i pochodnych (jak medyczne). Chociaż i we fizyce też się zdarzały "kanty". Ale to marginalne sytuacje. Najpóźniej po kilku latach wyłapywano takie przypadki i oszukane lub "ulepszone" artykuły były wycofywane. Gorzej jest w dziedzinach społecznych, co udowodnili już w 1997 roku Alan Sokal i Jean Bricmont ("Modne bzdury"). Tymczasem od tego momentu "pierdolec polityczno-poprawnościowy" nie tylko przyspieszył ale i się zintensyfikował. A AI to kolportuje, choć wydaje nie się, że raczej nie celowo, tylko z powodu masowości tego zjawiska. No ale w przypadku nauk społecznych to nie jest wina AI tylko ludzi uprawiających te dziedziny. Matematycy, fizycy czy nawet chemicy są bardzo uczuleni na wszelkie brednie. Nieco gorzej jest z biologią (np. co do dziedziczenia cech, kwestii płci, itd.). Doszło do tego, że znany biolog (i jednocześnie zatwardziały ateista) Richard Dawkins został publicznie sponiewierany słownie za krytykę bredni na temat m.in. płci.

Dnia 13.04.2026 o 23:34, H1M4W4R1 napisał:

Dnia 13.04.2026 o 21:58, VisualLab napisał:

W przeciwnym razie media dalej będą pisać brednie o halucynacji AI. Nie ma żadnych halucynacji - są tylko błędy i braki w algorytmach oraz brak rzetelnie przygotowanych baz danych.

To nie są błędy w algorytmach. Jak to kolega @ethanak powiada: problem siedzi zawsze przed monitorem. I w pełni się zgadzam z Jego twierdzeniem. Jak tworzę programy czy używam AI to zawsze źródłem problemu jest człowiek.

Ale który "problem" i przed którym monitorem? Ten "problem" co korzysta z AI? A może jednak to ten "problem", co tworzył (implementował czy trenował) AI? To wtedy zgoda. Jak AI wadliwie działa, to znaczy, że jego twórcy coś spieprzyli w trakcie jego tworzenia. Bo dobrze przygotowane AI w przypadku wadliwego zapytania (niekompletnego, sprzecznego, bezsensownego) powinno dać odpowiedź: "za mało danych", "nie mam na to odpowiedzi" albo "pytanie jest bez sensu". Co do kolegi @ethanak'a - zdarza się że ma rację, a bywa też tak, że czasem "halucynuje"

Dnia 13.04.2026 o 23:34, H1M4W4R1 napisał:

Dnia 13.04.2026 o 21:58, VisualLab napisał:

Obecnie furorę robią generatory obrazków, które tworzą portrety ludzi o dwóch głowach (te gorsze "ejaje") albo o siedmiu palcach lewej ręki (te lepsze "ejaje").

Ostatnio im się dość mocno poprawiło  Szczególnie jak używa się odpowiednich filtrów (Embedding, Lora) do generacji. Osobiście też uważam to za slop, ale do prototypowania jak najbardziej się nadaje.

Tak. Bo to raczej rozrywkowe zastosowanie.

Dnia 13.04.2026 o 23:34, H1M4W4R1 napisał:

Dnia 13.04.2026 o 21:58, VisualLab napisał:

Albo takie, co generują "ilustracje" elektroniczne, które bardziej przypominają zapieczony makaron na desce niż PCB z przylutowanymi elementami.

Bo żadne z tych generatorów obrazków nie są dostosowane do generowania schematów. To tak jakbyś chciał upiec ciasto wrzucając składniki do miski i ich nie mieszając. Efekt byłby podobny.

Prawidłowym podejściem jest zdefiniowanie formatu zapisu schematu w formie tekstowej i użycie kilku agentów LLM do budowy schematu oraz przeszukiwania internetu w poszukiwaniu niezbędnych informacji, by stworzyć konkretny projekt. Niestety problem leży w tym, że większość schematów dostępna jest w formatach obrazowych, a nie tekstowych. To powoduje gigantyczne problemy z dostępnością materiału źródłowego do tego zadania, a firmy od edytorów PCB mocno angażują się w projektowanie własnych, dedykowanych rozwiązań.

Ale nie o schematy elektroniczne mi chodziło. Miałem na myśli obrazy będące ilustracjami - np. udające prawdziwe fotografie gotowych modułów PCB. A co do schematów i ich generowania (lub weryfikacji), to myślę, że programy CAD dla elektroników mają wystarczające możliwości i są całkiem przyzwoite w działaniu.

Edytowano 14 kwietnia przez VisualLab

[H1M4W4R1]

5 minut temu, VisualLab napisał:

To powinno być standardem w zwracaniu wyników przez AI, bez specjalnego dopraszania się o źródło.

Efekt uboczny danych treningowych. Gdyby użyli sensownych danych (nawet tej nieszczęsnej Wikipedii, do której też mam zastrzeżenia) to byłoby znacznie lepiej.

6 minut temu, VisualLab napisał:

Co do matematyki, to lepiej będzie, jeśli wszelakie mniej i bardziej zaawansowane obliczenia będą wykonywać programy CAS (Maple, Mathcad, Mathematica) czy środowiska obliczeniowe (Matlab, Scilab), które są do tego całkiem nieźle przystosowane.

Numpy + Scipy też są dobre  O ile można nienawidzić Pythona za styl i bałagan, o tyle jeżeli chodzi o wygodę liczenia czegokolwiek to bije Matlaba na głowę (jestem programistą i nie przepadam za tym jak drewniane są narzędzia matematyczne).

8 minut temu, VisualLab napisał:

A jak ktoś ma naprawdę duże wymagania, to AI mu nie pomoże. Bo do różnorakich zastosowań dziedzinowych typu modelowanie czy symulacje to i tak trzeba użyć wyspecjalizowanego narzędzia (jakieś Chemcady, Solidworksy, Gaussian'y, itd.).

Fusion 360 już eksperymentuje z AI do tworzenia modeli CAD. Na ten moment jest to powiedzmy... prototyp, ale coś prostego już daje radę narysować. Pierwsze modele tekstowe i obrazkowe też były beznadziejne, a obecnie czasem trzeba się nieźle wpatrzeć, by dostrzec, że to AI.

9 minut temu, VisualLab napisał:

Ale który "problem" i przed którym monitorem? Ten "problem" co korzysta z AI? A może jednak to ten "problem", co tworzył (implementował czy trenował) AI? To wtedy zgoda.

Jak uderzysz się młotkiem w palec to też zwalisz winę na producenta młotka, że nie dodał osłonki? Większość osób po prostu zbyt mocno przywykła do tego, że narzędzia traktują użytkownika jak małpę. Zauważ, że AI to dość skomplikowane narzędzie, do którego siadają osoby bez przeszkolenia. Pomyśl, co by było gdyby takie osoby i w takiej skali posadzić do jakiegoś narzędzia fizycznego o podobnym stopniu "skomplikowania" (o ile samo AI jest proste do zbudowania, o tyle przewidzenie jego działania bez stosownej wiedzy jest praktycznie awykonalne) np. reaktorów atomowych.

Ogólnie soft powinien działać, ale w obecnych czasach i standardach kodu to AI działa bardzo dobrze (pracowałem jako programista gier, widziałem już chyba wszystko co możliwe).

13 minut temu, VisualLab napisał:

A co do schematów i ich generowania (lub weryfikacji), to myślę, że programy CAD dla elektroników mają wystarczające możliwości i są całkiem przyzwoite w działaniu.

Właśnie, że tutaj akurat są bardzo słabe. Szczególnie auto-routery, które nie uwzględniają pól magnetycznych, tego że ścieżki/wylewki moga być antenami i kupy innych "pierdołek", które powodują uwalenie testów EMI  Tutaj AI ma spore pole do popisu w kontekście analizy i wykrywania błędów, nawet takich głupich jak brak rezystorów podciągających na układach CMOS, przez co nie będą działać poprawnie (przykład z autopsji). Nawet jak wstępnie ułożą komponenty w sensownych grupach na bazie oczekiwanych lokalizacji złączek to już byłoby całkiem nieźle. 

AI to nie jest pracownik, AI to narzędzie, które ma przyspieszyć pracę i robi to całkiem nieźle (soft i debugowanie w C zajmuje mi teraz około godziny od zamocowania PCB do stoiska testowego do gotowej wersji z weryfikacją podstawowego działania, zostają aby testy długoterminowe jak analiza termiczna i wytrzymałościowa).

[Harnas]

Dnia 7.04.2026 o 00:45, VisualLab napisał:

wymusza konieczność używania obejść w postaci kontenerów

Standard od jakichś 10 lat  Nie ważne Python, Java czy JS.
 

Dnia 7.04.2026 o 14:55, VisualLab napisał:

Nie zrozumieliśmy się. To co ma Python to jest bardzo skromna (wręcz szczątkowa) namiastka. To, że da się w kodzie wstawić instrukcję sprawdzającą typ zmiennej czy wymuszać interpretację (namiastka rzutowania) to za mało, żeby mówić o systemie typów.

W teorii tak. W praktyce często używa się bibliotek napisanych w C/C++/Rust, gdzie pod spodem faktycznie są typy. Na przykłąd numpy, Polars, Pytorch.

Dnia 15.04.2026 o 00:59, VisualLab napisał:

Co do matematyki, to lepiej będzie, jeśli wszelakie mniej i bardziej zaawansowane obliczenia będą wykonywać programy CAS (Maple, Mathcad, Mathematica) czy środowiska obliczeniowe (Matlab, Scilab), które są do tego całkiem nieźle przystosowane. Ponadto WolframAlpha działa już dość długo i to całkiem nieźle. Jego darmowa wersja jest w zupełności wystarczająca dla uczniów, studentów i hobbystów.

W R&D rządzi Python. Są nisze, gdzie używa się innych rzeczy. Ale coraz trudniej o to, bo normą jest teraz "data driven" a w obróbce danych i wizualizacji, Python nie ma sobie równych.

[VisualLab]

Dnia 15.04.2026 o 01:24, H1M4W4R1 napisał:

Dnia 15.04.2026 o 00:59, VisualLab napisał:

To powinno być standardem w zwracaniu wyników przez AI, bez specjalnego dopraszania się o źródło.

Efekt uboczny danych treningowych. Gdyby użyli sensownych danych (nawet tej nieszczęsnej Wikipedii, do której też mam zastrzeżenia) to byłoby znacznie lepiej.

Otóż to. Czyli wracamy do kwestii przygotowania wiarygodnych (zweryfikowanych) danych, które są używane do trenowania AI.

Dnia 15.04.2026 o 01:24, H1M4W4R1 napisał:

Dnia 15.04.2026 o 00:59, VisualLab napisał:

Co do matematyki, to lepiej będzie, jeśli wszelakie mniej i bardziej zaawansowane obliczenia będą wykonywać programy CAS (Maple, Mathcad, Mathematica) czy środowiska obliczeniowe (Matlab, Scilab), które są do tego całkiem nieźle przystosowane. 

Numpy + Scipy też są dobre  O ile można nienawidzić Pythona za styl i bałagan, o tyle jeżeli chodzi o wygodę liczenia czegokolwiek to bije Matlaba na głowę (jestem programistą i nie przepadam za tym jak drewniane są narzędzia matematyczne).

Co do nienawiści do Pythona - myślę, że raczej jest to krytyczna opinia o tym języku, która powstała wskutek doświadczania jego braków, dziwactw i niedociągnięć. Poza tym wiele zależy jakiego narzędzia ktoś potrzebuje. To jest zupełnie zdrowe podejście, bo narzędzia bywają lepiej lub gorzej zaprojektowane.

Co do obliczeń - wiele zależy od tego jakie obliczenia ktoś wykonuje. Wielu ludziom (w firmach czy na uczelniach) do obliczeń projektowych wystarczyłby Mathcad, Matematica czy Maple (czyli klasyczny CAS). Ci co mają różne wyniki z pomiarów laboratoryjnych z powodzeniem mogliby użyć Excela czy Origina. Z kolei ci co potrzebują wykonać skomplikowane symulacje użyją wyspecjalizowanych narzędzi (np. Gaussian). Do wykonania testów na danych (chemia, biologia) bez problemu można zastosować Statisticę. Każdy z tych przypadków ma tę zaletę, że nie wymaga nauki programowania. Oprogramowanie jest dostosowane do dziedziny. Wadą jest konieczność zakupu dość kosztownej licencji. Uczelnie czy duże firmy nie mają z tym problemów. Jednakże te programy są poza zasięgiem hobbystów, uczniów czy małych firm (zakładam, że nie piracą oprogramowania). Ale coś niecoś się znajdzie wśród freeware czy open source. Zamiast Excela często wystarczy LibreOffice Calc (całkiem przyzwoity arkusz kalkulacyjny, np. też ma solver). Do wykonania obliczeń do prostszych projektów można użyć SMath. Podstawowe testy statystyczne da się wykonać w arkuszu kalkulacyjnym (czyli np. w LibreOffice Calc).

Zaletą rozwiązań polegających na pisaniu skryptów [Matlab, Python, R (do statystyki)] jest możliwość sterowania tokiem obliczeń, co nie zawsze jest możliwe przy zastosowaniu gotowego oprogramowania (jak w/w). Szczególnie gdy ilość danych jest liczona w gigabajtach (z tego co pamiętam Excel obsługuje maksymalnie około 2 mln wierszy). Wadą rozwiązań polegających na pisaniu skryptów jest konieczność: (1) nauczenia się programowania, (2) solidnego przetestowania pracy skryptu. Ta druga wada jest niestety dużo poważniejsza, bo języki skryptowe posiadają wiele uproszeń (np. brak statycznego systemu typów). Po drugie ich składnia zawiera różne dziwactwa (szczególnie Python i R). Zatem każdy wybierze co chce lub raczej co jest w stanie użyć i obsłużyć.

W laboratoriach kontroli jakości w firmach małych czy średniej wielkości praktycznie używane są programy wyspecjalizowane. One często współpracują z jakimś sprzętem. Laborant (np. chemik, biolog, itd.) nie ma czasu, wiedzy (i najczęściej też chęci) pisania skryptów - potrzebuje narzędzia które wykona określoną pracę. Rzadko zdarza się ktoś, kto chce pisać programy czy skrypty. Poza tym w takich firmach często jest zbyt duża odpowiedzialność za to co się robi, więc raczej mało kto chciałby ryzykować potencjalne kłopoty (np. gdy wskutek błędnego działania programu lub skryptu wyniki obróbki danych zawierałyby błędy, które później skutkowałyby awarią urządzenia, instalacji czy wypadkiem).

Dnia 15.04.2026 o 01:24, H1M4W4R1 napisał:

Dnia 15.04.2026 o 00:59, VisualLab napisał:

A jak ktoś ma naprawdę duże wymagania, to AI mu nie pomoże. Bo do różnorakich zastosowań dziedzinowych typu modelowanie czy symulacje to i tak trzeba użyć wyspecjalizowanego narzędzia (jakieś Chemcady, Solidworksy, Gaussian'y, itd.).

Fusion 360 już eksperymentuje z AI do tworzenia modeli CAD. Na ten moment jest to powiedzmy... prototyp, ale coś prostego już daje radę narysować. Pierwsze modele tekstowe i obrazkowe też były beznadziejne, a obecnie czasem trzeba się nieźle wpatrzeć, by dostrzec, że to AI.

Dobra wiadomość. Zatem przynajmniej niektóre z dziedzin zyskają na rozwoju AI.

Dnia 15.04.2026 o 01:24, H1M4W4R1 napisał:

Dnia 15.04.2026 o 00:59, VisualLab napisał:

Ale który "problem" i przed którym monitorem? Ten "problem" co korzysta z AI? A może jednak to ten "problem", co tworzył (implementował czy trenował) AI? To wtedy zgoda.

Jak uderzysz się młotkiem w palec to też zwalisz winę na producenta młotka, że nie dodał osłonki? Większość osób po prostu zbyt mocno przywykła do tego, że narzędzia traktują użytkownika jak małpę. Zauważ, że AI to dość skomplikowane narzędzie, do którego siadają osoby bez przeszkolenia. Pomyśl, co by było gdyby takie osoby i w takiej skali posadzić do jakiegoś narzędzia fizycznego o podobnym stopniu "skomplikowania" (o ile samo AI jest proste do zbudowania, o tyle przewidzenie jego działania bez stosownej wiedzy jest praktycznie awykonalne) np. reaktorów atomowych.

Ogólnie soft powinien działać, ale w obecnych czasach i standardach kodu to AI działa bardzo dobrze (pracowałem jako programista gier, widziałem już chyba wszystko co możliwe).

Hm... tak i nie. To zależy. W przypadku używania młotka problem urazów można ograniczyć poprzez użycie rękawic roboczych, więc tak jak piszesz, to użytkownik powinien o siebie zadbać (BHP). Ale w przypadku bardziej skomplikowanych narzędzi mają one pewne osłony czy zabezpieczenia. Wiadomo, że szlifierki czy piły mają różne osłony. A maszyny przemysłowe (np. centra obróbki, frezarki) często są konstruowane tak, że oprócz osłon mają czujniki. Pracują same, człowiek tylko je nadzoruje naciskając różne "guziki" (albo zdalnie przez wewnętrzną sieć). A i tak czasem zdarzają się wypadki (zwykle przez czyjąś głupotę, nie zawsze przez poszkodowanego). Zmniejszanie prawdopodobieństwa wystąpienia wypadku jest raczej pożądane, także w przypadku oprogramowania.  Oczywiście zawsze znajdzie się jaki "spec", co "wie lepiej" i zdejmie osłonę z tokarki, piły czy szlifierki a po jakimś czasie jest znany jako "Józek bez ręki"  Zatem, tak jak piszesz, także w przypadku oprogramowywania ludzie będą robili głupie błędy. Ale miło jest mieć jakieś zabezpieczenie przed wadliwym działaniem (nie mam na myśli cenzury).

Dnia 15.04.2026 o 01:24, H1M4W4R1 napisał:

Dnia 15.04.2026 o 00:59, VisualLab napisał:

A co do schematów i ich generowania (lub weryfikacji), to myślę, że programy CAD dla elektroników mają wystarczające możliwości i są całkiem przyzwoite w działaniu.

Właśnie, że tutaj akurat są bardzo słabe. Szczególnie auto-routery, które nie uwzględniają pól magnetycznych, tego że ścieżki/wylewki mogą być antenami i kupy innych "pierdołek", które powodują uwalenie testów EMI  Tutaj AI ma spore pole do popisu w kontekście analizy i wykrywania błędów, nawet takich głupich jak brak rezystorów podciągających na układach CMOS, przez co nie będą działać poprawnie (przykład z autopsji). Nawet jak wstępnie ułożą komponenty w sensownych grupach na bazie oczekiwanych lokalizacji złączek to już byłoby całkiem nieźle. 

Masz rację. Zdecydowanie przydałoby się takie wspomaganie podczas projektowania. Urządzenia są coraz bardziej złożone, więc wskazane jest, aby program sugerował/podpowiadał/przypominał/wskazywał różne "drobiazgi" podczas projektowania.

Dnia 15.04.2026 o 01:24, H1M4W4R1 napisał:

AI to nie jest pracownik, AI to narzędzie, które ma przyspieszyć pracę i robi to całkiem nieźle (soft i debugowanie w C zajmuje mi teraz około godziny od zamocowania PCB do stoiska testowego do gotowej wersji z weryfikacją podstawowego działania, zostają aby testy długoterminowe jak analiza termiczna i wytrzymałościowa).

Oczywiście, że AI to nie pracownik. AI dostosowane do konkretnego zagadnienia jest bardzo użyteczne.

To wszechwiedząca AI jest ułomna. I nie wydaje mi się, żeby ludzie aż tak jej potrzebowali. Kiedy dajmy na to student pyta AI jak przeprowadzić test ANOVA na konkretnych danych to jest OK (niektórzy studenci brzydzą się książkami, nawet w postaci PDF). AI mu pokaże jak wykonać zadanie. Wadą jest to że, wielu z takich studentów skopiuje i wklei wyniki do sprawozdania, ale nie zrozumie jak ten test się robi (i nie chodzi tu o wykonanie rachunków, te może wykonać program). Ale to nie jest zmartwienie twórców AI. A teraz weźmy inny przypadek. Uczeń pyta AI co się znajduje na krańcu wszechświata. I co mu ma odpowiedzieć AI? Nikt tego nie wie. Zatem prawidłowa odpowiedź AI powinna brzmieć: "nie wiadomo czy istnieje coś takiego jak kraniec wszechświata. Nie ma na to odpowiedzi." Inny przypadek - uczeń naoglądał się nagrań na YouTube i pyta: "czy witamina C leczy raka?" Ciekawe co dostanie w odpowiedzi. Weźmy jeszcze cięższy przypadek, uczeń pyta: "ile jest płci?" albo "czy Mahomet była kobietą?" Pytania zwyczajne, czasem śmieszne lub dziwne, a raczej były takie jakieś 20 lat temu. Teraz są upolitycznione, bo liczba wrogów nauki rośnie chyba wykładniczo. I tu wszechwiedząca AI robi olbrzymie szkody, bo aktywnie kolportuje bzdury, szerzy ciemnotę i konfliktuje ludzi. Ale trzeba też przyznać, że wina leży nie bezpośrednio w AI jako kodzie źródłowym, tylko zarządach korporacji, które wymuszają na programistach określone kształtowanie zachowania AI. Czyli dawanie odpowiedzi za wszelką cenę, odpowiedzi rozwlekłe i rozwodnione. A często powinny być krótkie: "pytanie jest bez sensu" albo "na to pytanie nie ma odpowiedzi" czy wreszcie "pytanie jest głupie".

Edytowano 25 kwietnia przez VisualLab

[VisualLab]

Dnia 19.04.2026 o 23:02, Harnas napisał:

Dnia 7.04.2026 o 00:45, VisualLab napisał:

wymusza konieczność używania obejść w postaci kontenerów

Standard od jakichś 10 lat  Nie ważne Python, Java czy JS.

Taaak, świetny standard. Zupełnie podobnie, jak poprzednich stuleciach (renesans, barok, oświecenie) standardem było "leczenie" poprzez upuszczanie krwi i stosowanie lewatyw. Co do kontenerów - raczej należałoby nad takim stanem rzeczy ubolewać, gdy standardem jest patologia. Kontenery są protezą, kiepską próbą obejścia (a nie naprawy) problemów z architekturą systemu operacyjnego, wzorowanego na Unix'ie (czyli głównie Linux). Architektura taka była wystarczająca w latach 70 i 80-tych XX wieku. Ale od tamtej pory minęło przeszło 50 lat. Tak więc kontenery to kiepski skutek wcześniejszej patologii.

Dnia 19.04.2026 o 23:02, Harnas napisał:

Dnia 7.04.2026 o 14:55, VisualLab napisał:

Nie zrozumieliśmy się. To co ma Python to jest bardzo skromna (wręcz szczątkowa) namiastka. To, że da się w kodzie wstawić instrukcję sprawdzającą typ zmiennej czy wymuszać interpretację (namiastka rzutowania) to za mało, żeby mówić o systemie typów.

W teorii tak. W praktyce często używa się bibliotek napisanych w C/C++/Rust, gdzie pod spodem faktycznie są typy. Na przykłąd numpy, Polars, Pytorch.

W teorii, czyli co? W praktyce to biblioteki te są napisane nie tylko w C i C++ ale przede wszystkim we Fortranie. Czy są jakieś napisane w Rust? Może jakieś nieliczne są. Rust jest zbyt nowy, więc jeszcze nie ma zbyt rozbudowanej liczby bibliotek. Do tego jego składnia i reguły nie przyspieszają jego rozwoju. 

Dnia 19.04.2026 o 23:02, Harnas napisał:

Dnia 15.04.2026 o 00:59, VisualLab napisał:

Co do matematyki, to lepiej będzie, jeśli wszelakie mniej i bardziej zaawansowane obliczenia będą wykonywać programy CAS (Maple, Mathcad, Mathematica) czy środowiska obliczeniowe (Matlab, Scilab), które są do tego całkiem nieźle przystosowane. Ponadto WolframAlpha działa już dość długo i to całkiem nieźle. Jego darmowa wersja jest w zupełności wystarczająca dla uczniów, studentów i hobbystów.

W R&D rządzi Python. Są nisze, gdzie używa się innych rzeczy. Ale coraz trudniej o to, bo normą jest teraz "data driven" a w obróbce danych i wizualizacji, Python nie ma sobie równych.

Eee, tam. Gadanie. Zestawienia popularności z Tiobe czy SO nie są miarodajne. Tiobe to firma która z Pythona żyje, więc nie jest wiarygodna. Do tego te zestawienia agregują wszytko na dany temat, więc nie wiadomo jaką ich część stanowi szum medialny. Prawdopodobnie największą część stanowią pytania o Pythona (bo ktoś coś słyszał, że wszyscy kuple to w Pythonie..., więc oni by też spróbowali, itd.). A jak jest naprawdę to nie wiadomo, bo kto niby ma prowadzić te zestawienia? I jak zebrać dane w wielu miejsc na świecie? Ile to by kosztowało? Firmy używają różnych narzędzi, różnych języków programowania do różnych prac. Więc to "rządzenie Pythona w R&D" to taka mieszanina "legend miejskich" z "zabobonami wiejskimi" (i mitami rozpowszechnianymi przez nerdów pythonowych). Najbardziej prawdopodobnym przypadkiem jest taki, że używa się (w firmach i instytucjach) różnych narzędzi przez różnych pracowników w tym samym czasie, w zależności od wykonywanych prac. Więc używane są zarówno arkusze kalkulacyjne jak i kompilatory (czy IDE) C, C++, Javy, Rusta a nawet Object Pascala, ale także programów jak Statistica, Matlab i wiele innych. Im większa firma, tym więcej tej różnorodności, bo i potrzeby są różne.

Co do tego, że "normą jest teraz "data driven"". To jest zwyczajny bełkot medialny i nie widzę potrzeby powielania go tutaj. Dane zawsze miały znaczenie. Nawet 200 lat temu, kiedy statystyka raczkowała a przemysł gwałtownie się rozwijał (a na dobrą sprawę to i wcześniej, tylko na niewielką skalę). Tylko że ówcześni ludzie nie mieli narzędzi do "masowego mielenia liczb". Dopiero tak gdzieś od lat 80-tych XX wieku większość uczelni i firm dostała taką możliwość, jak PCty staniały. Media trąbią o "data scientist" ale tak naprawdę nie ma czegoś takiego. Są tylko 2 dziedziny od przetwarzania danych: informatyka i statystyka. Innych nie ma. Hasła typu "data driven" czy "data scientist" to bełkot marketingowy rozpowszechniany przez wielkie korpo, mający na celu przekonać klientów do wydawania pieniędzy. Ten bełkot ma sugerować, że powstało coś nowego, ale to nieprawda. A do obróbki danych od dawna istnieje wiele różnych programów. Wcale nie musi to być Python. I wcale nie jest najłatwiejszym i najszybszym rozwiązaniem - to jest zwyczajny zabobon około-informatyczny. Być może jest tylko jednym z tańszych (bo wyspecjalizowane narzędzia bywają dość drogie).

Co do wizualizacji - to zależy co ktoś rozumie przez wizualizację. A wizualizacja to nie tylko wykresy. To schematy różnego typu, diagramy, harmonogramy, schematy reakcji chemicznych i wiele innych sposobów przedstawiania danych. Użycie do tego celu Pythona wcale nie jest najszybsze i najwygodniejsze. Wręcz przeciwnie, szczególnie jak ktoś nie zna Pythona. Zdecydowanie szybciej i lepiej wykona wizualizacje w jakimś wyspecjalizowanym programie.

Fiksacja na punkcie Pythona to bardziej zwykła moda. Była moda na Web i XML (ok. 2000 r.), była na blockchain (z 15-10 lat temu), teraz jest na AI i Pythona. Nie ma co siać korporacyjnej propagandy lub jej ulegać. Należy być zawsze nieco septycznym i pytać: "po co ktoś coś tak nachalnie lansuje, jaki ma w tym interes, co chce zyskać i czyim kosztem?". Bo to m.in. dzięki zdrowemu sceptycyzmowi rozwija się nauka i technika.

Edytowano 25 kwietnia przez VisualLab