https://twitter.com/eevee/status/1410037309848752128
tl;dr: istnieją narzędzia, które "uczą się" pisania kodu na bazie open-source a potem wspomagają pisanie kodu, tylko jeśli takie narzędzie podpowie nam coś praktycznie żywcem z GPLowej biblioteki, to czy to sprawia że nasz kod tez powinien automatycznie być GPLowy? :) Chodzi o takie narzędzia jak
a czym to się różni od tego, jakbyś sam ukradł skopiował kod?
koniec końców to ty decydujesz co pushujesz i dystrybuujesz
a czym to się różni od tego, jakbyś sam ukradł skopiował kod?
jw, różni się tym że jak snippet podpowie ci code-completion w IDE to nawet nie przyjdzie ci do głowy że może właśnie ukradłeś jakiś kawałek na GPLu
Wydaje mi się, że trudno o bardziej dosłowne wyrażenie czym jest "dzieło pochodne".
GPL - chyba istnieją również licencje które nie zezwalają na mieszanie z nim? W takim wypadku użycie takiego narzędzia zupełnie wykracza poza dopuszczalne normy.
Co ja o tym sądzę? Zastanawiam się ile można wziąć sobie cudzego kodu na prawach cytatu. No bo każdy używa ifa, a jak przecież jeden if jest na GPL to nie znaczy że wszystkie ify są na GPL
@Shalom:
zazwyczaj snippety w IDE robią bardzo proste rzeczy np. generują forki itp., a nie piszą implementacje całych funkcji.
@enedil niby tak, ale zauważ ze zgodnie z opisem to narzędzie tworzy nowy kod, na podstawie wyuczonego modelu, nie zwraca żywcem snippetów na których się uczyło.
@WeiXiao te narzędzia podpowiadają duo większe bloki niż jedna linijka czy jedno wywołanie funkcji, bo często pewne patterny się powtarzają, np. otwarcie pliku i oczytanie zawartości, albo jakaś pętla filtrująca itd
Shalom napisał(a):
@WeiXiao te narzędzia podpowiadają duo większe bloki niż jedna linijka czy jedno wywołanie funkcji, bo często pewne patterny się powtarzają, np. otwarcie pliku i oczytanie zawartości, albo jakaś pętla filtrująca itd
To już jest szersze pytanie o licencje do snippetów, quora
Imho to ułatwienie to doskonała okazja do szpiegostwa technologicznego. Takie dodatki do IDE są rejestrowane i dostawca podpowiedzi wie jaki kod i komu jest podpowiadany. Ergo wie nad czym pracuje firma X, która zakupiła licencje swoim pracownikom. Poza tym to kolejny krok w stronę wiązania programowania z chmurą i w sumie tylko to jest wystarczającą przyczyną, aby mi się takie podpowiadanie nie podobało.
Ale że kto szpieguje GitHub? USA? Microsoft?
Doskonały argument, żeby pisać kod bez komentarzy, z nazwami wszystkiego dupa<n> lub w gwarach języka polskiego. ;) Bo inaczej będzie się pasło miliarderów z MS za pośrednictwem ich AI.
@Shalom: O ile rozumiem działanie tych narzędzi, to one copypastują opublikowane na "jakiejś" licencji kawałki kodu. Jeżeli nie masz podanego źródła (z tego co pamiętam, to któreś z nich podawało), to obowiązuje cię licencja narzędzia, chociaż wciąż ponosisz ryzyko, bo to, że Alice nieświadomie kupiła od Boba kod, który ten ukradł Charliemu oznacza, że Alice nie jest przestępcą, ale też w momencie kiedy Charlie powie jej "to mój kod, przestań go używać" będzie musiała usunąć to ze swojego produktu.
Druga sprawa to bezpieczeństwo - kopiowanie z przypadkowych miejsc kodu, którego się nie rozumie to trochę przepis na katastrofę.
Trzecia - może po 30 latach nadszedł czas na włączenie do biblioteki standardowej Javy jakiegoś myku na otwarcie i odczyt pliku jedną linijką.
Bardzo dobrze, że taki soft powstaje, i że powoduje, że ludzie zaczynają zwracać uwagę na takie kwestie. Może w końcu pozbędziemy się konceptu praw autorskich do kodu.
Na chłopski rozum, równie dobrze byli pracodawcy mogą zarzucić, że pracując dla obecnej firmy wynosisz ich kod - bo nauczyłeś się pewnych technik, patternów itd. m.in. u nich, czytając i pisząc ich kod. Mogłeś nawet po godzinach samemu analizować źródła bibliotek GPL i potem (po tygodniach, miesiącach) to samo odtworzyć w swoim projekcie nawet nie wiedząc dokładnie, skąd czerpiesz inspirację.
Ogólnie przypuszczam, że skoro pierwsze lepsze korpo ma swoje regułki odnośnie tego, z jakich licencji nie chcą korzystać żeby nie wtopić, to taka Codota raczej zorganizowała sobie dupochron w postaci zaplecza prawników i stosu makulatury, zanim (o ile) zaczęli uczyć swoje modele na kodzie GPL.
siloam napisał(a):
Takie dodatki do IDE są rejestrowane i dostawca podpowiedzi wie jaki kod i komu jest podpowiadany. Ergo wie nad czym pracuje firma X, która zakupiła licencje swoim pracownikom.
No tak i nie, równie dobrze możesz powiedzieć, że dostawca IDE stosuje szpiegostwo przemysłowe, bo może sprawdzić co kto wpisuje w ich narzędziu. Każdy OS może mieć wbudowanego keyloggera - wtedy to nawet gorzej, bo znają nie tylko kod ( ͡° ͜ʖ ͡°)
Z kolei np. Google zna wszystkie tajne przez poufne służbowe maile, jeżeli Twoja firma używa G Suite.
Jak chcesz gwarancji, że na pewno nikt nie szpieguje i nie przemyca syfu to musisz namówić swoją firmę do napisania własnego TempleOS wraz z IDE :D :D :D
Fajnie, że ktoś myśli o tym, żeby nie kopiować. Czasem jednak żeby coś udowodnić, trzeba złamać ewentualne zabezpieczenia i zdekompilować kod, co może okazać się nielegalne. Tak że ten :)
Sensacyjny Sebastian napisał(a):
Bardzo dobrze, że taki soft powstaje, i że powoduje, że ludzie zaczynają zwracać uwagę na takie kwestie. Może w końcu pozbędziemy się konceptu praw autorskich do kodu.
Trochę popłynąłeś. Komercyjny soft to jednak dość istotna część gospodarki. W przypadku OSS też masz wiele projektów licencjonowanych podwójnie np. GPL + komercyjna licencja
superdurszlak napisał(a):
Na chłopski rozum, równie dobrze byli pracodawcy mogą zarzucić, że pracując dla obecnej firmy wynosisz ich kod - bo nauczyłeś się pewnych technik, patternów itd. m.in. u nich, czytając i pisząc ich kod. Mogłeś nawet po godzinach samemu analizować źródła bibliotek GPL i potem (po tygodniach, miesiącach) to samo odtworzyć w swoim projekcie nawet nie wiedząc dokładnie, skąd czerpiesz inspirację.
W moim korpo musisz mieć pozwolenie na włączenie biblioteki do projektu. Oprócz dojrzałości technicznej badana jest też licencja, więc można zapomnieć o GPL, czy innych zakażających licencjach. Pewnie da się przepchnąć GPL/LGPL w przypadkach zgodnych z licencjami, ale każdorazowo jest to badane i trzeba podać co konkretnie się będzie z takim kodem robić, czy jest to produkt wewnętrzny, SaaS, czy artefakt lecący do klienta.
Moim zdaniem to wciąż naruszenie praw autorskich. To nie broń strzela tylko człowiek przy użyciu broni.
Inną sprawą jest to czy prawa autorskie w ogóle powinny istnieć. Moim zdaniem nie.
Wszystko zależy od interpretacji podpowiedzianego kodu. Na logikę korzystanie z cudzego kodu (nawet open-source) w rozwiązaniach komercyjnych jest jawnym naruszeniem licencji GPL. A więc jeśli takie Codota uczy się poprzez analizę kodu GPL, ale samo w sobie nie jest narzędziem GPL to łamie założenia licencji.
wartek01 napisał(a):
A więc jeśli takie Codota uczy się poprzez analizę kodu GPL, ale samo w sobie nie jest narzędziem GPL to łamie założenia licencji.
Ciekawe że jeśli Codota to człowiek i uczy się z kodu GPL pisać kod komercyjny to nie łamie licencji GPL
patrząc na to narzędzie to kolejna cegiełka do wykluczenia programistów z branży czy nie?
@KamilAdam: ciekawe, ale nie do końca. W przeciwieństwie do maszyn ludzie są w stanie stworzyć coś nowego, tj. kod generowany przez AI nie jest wymyślony przez AI, to jedynie synteza poprzednich - a więc wiemy, że jest to na 100% kod zsyntezowany z tego, co napisano wcześniej. W przypadku człowieka takiej pewności nie masz, bo przecież ktoś kiedyś tego Hello Worlda w końcu napisał po raz pierwszy.
@veneficus: raczej nie bo żadna trochę większa firma nie pozwoli, aby jej kod trafił do Codoty, natomiast kod dostępny w źródłach publicznych w 90% jest praktycznie bezużyteczny jeśli nie liczyć snippetów. Wystarczy wspomnieć, że w każdej firmie mającej politykę bezpieczeństwa z prawdziwego zdarzenia Grammarly jest zabronione. Póki co tego typu narzędzia są IMO ciekawostką, bo jak widziałem na prezentacji to te snippety bardzo odbiegają od tego co chce się napisać, a nawet i wtedy zazwyczaj trzeba poprawiać po nich.
Najlepsze jest to, że wielokrotnie widziałem scenariusz, że z "normalnymi" podpowiedziami wyjdzie ci szybciej.
Skoro pytasz o takie narzędzia, to znaczy, że programowanie nie jest dla Ciebie. Spróbuj w jakiejś piekarni czy coś.
Dla mnie takie rzeczy chwilowa moda i rozwiązywanie złego problemu. Zakładanie, że programiści mają problem z klepaniem nowego kodu.
Niech ktoś zrobi tool, który będzie sam refaktorował spaghetti do super czystej architektury, to wtedy pogadamy.
Albo niech ktoś zrobi tool, który będzie w stanie zrozumieć duży projekt, a potem będzie robił nowemu programiście on-boarding.
Ale nie, bo przecież przeciętny programista nie umie sam napisać funkcji i musi używać toola do tego. To największy palący problem :D
Jeśli ktoś chciałby naprawdę pchnąć programowanie do przodu, to lepiej ten czas poświęcić w inny sposób - np. napisać przydatną bibliotekę albo zająć się utrzymywaniem istniejącej. Tym sposobem możemy zlikwidować całą klasę problemów. Zamiast pisać całą funkcję, to po prostu użyjemy funkcji z biblioteki. I machine learning nie będzie potrzebne. Jeśli masz np. bibliotekę do kompresji danych i masz tam funkcję compressToZip, to nic więcej ci nie potrzeba. Po co pisać nową funkcję compressToZip i po co ma się autogenerować algorytmami Machine Learning kod, który będzie robił to samo, co istniejąca biblioteka? Gdzie tu sens?
@LukeJL:
Widzę to trochę inaczej. Nie widze nic złego w podpowiadaniu ... to jest po prostu logiczna konsekwencja czegoś co jest od dawna w każdym większym IDE - zamiast zakuwać 20000 funkcji bibliotecznych i tych napisanych przez kolegów używamy podpowiadania. Normalka. Tu wchodzi na kolejny poziom, bo podpowiadane są całe kawałki kodu.
To, że takie kawałki mogłyby być czasem wydzielone do osobnych funkcji to ... przeważnie nieprawda, a nawet jeśli prawda to nie będzie działać. Z 2 powodów.
Powód pierwszy. Nasze języki oprogramowania obsysają po całości i wiele funkcji nie da się wyrazić w sposób generyczny, tylko trzeba klepać.
(czuje się jak idiota za każdym razem jak pisze w Kotlinie odpowiednik sequenceA https://hackage.haskell.org/package/base-4.15.0.0/docs/Prelude.html#v:sequenceA).
Zresztą ta miernota jezyków urosła wręcz do rangi osobnej dziedziny - znanej pod nazwą design patterns.
Drugi problem to ograniczona pojemność ludzkich mózgów. Co z tego, że zrobisz miliony funkcji bibliotecznych jak nikt nie będzie nawet wiedział jak i gdzie ich szukać.
(nazywa się compressZip, a może zipCompress, a może compress, a może shrink, shrinkZip, crunch ? i w ogóle jaka to biblioteka?)
Jeszcze gorzej jest z patternami.
Większość programistów codziennie klepie kawałki kodu typu:
List<Customer> allCustomers = new ArrayList<>();
for( group: customersGroups) {
allCustomers.addAll(group.getCustomers());
}
zamiast użyć generycznego fold. A fold nawet nie jest jeszcze najbardziej ogólnym rozwiązaniem. Bo można to jeszcze bardziej uogólnić i używać cata.
Tylko wtedy na twarz dostaje się pojęcia typu F-algebra, Functor itp. (w zamian za to można używać całej gamy tzw. recursion schemes).
Wychodzi na to, że aby nie pisać pierdołowatych pętli to trzeba spędzić rok z teorią kategorii, a potem jeszcze wywalić javę (czy np. kotlina) bo takie abstrakcje
w tych językach są nie do wyrażenia (sensownego). Mało komu będzie się chciało. Użyjemy patternu - czyli copy/paste tylko z mniej śmierdzącą nazwą.
Podpowiadanie pozwoli też czasami uniknąć typowych błedów (kto notorycznie zapominał o index++ w pętli while - ten wie)
Dlatego jednak takie toole mają sens. Jak któregoś dnia AI zaczną podpowiadać: widzę, że robisz hylomorphism, pozwól, że zrobię Ci to w jednej linijce (czyli czyszczenie kodu)- to będzie już zupełnie dobrze.
jarekr000000 napisał(a):
Widzę to trochę inaczej. Nie widze nic złego w podpowiadaniu ... to jest po prostu logiczna konsekwencja czegoś co jest od dawna w każdym większym IDE
I jest to OK, tak samo jak copy-paste z SO, tak długo, jak programista wie co robi kod, który napisał.
To, że takie kawałki mogłyby być czasem wydzielone do osobnych funkcji to ... przeważnie nieprawda, a nawet jeśli prawda to nie będzie działać. Z 2 powodów.
Ale jednak pewne języki mają tendencję do sztucznego wchodzenia w nadmierną niskopoziomowość. Oczywiście zawsze jest pytanie o granicę.
Dlatego jednak takie toole mają sens. Jak któregoś dnia AI zaczną podpowiadać:
widzę, że robisz hylomorphism, pozwól, że zrobię Ci to w jednej linijce(czyli czyszczenie kodu)- to będzie już zupełnie dobrze.
Statyczna analiza kodu zawsze na propsie. Ileś już kolejnych zespołów zmusiłem do wprowadzenia 0 finding policy i zawsze zaczynało się od bólu i płaczu, poprzez delikatne marudzenie o "false positive" i "jak to zrefaktoruję, to będzie mniej czytelnie" a kończyło na ogólnym przekonaniu, że warto pilnować nawet głupot, bo pracuje się dużo lepiej.
jarekr000000 napisał(a):
Jeszcze gorzej jest z patternami.
Większość programistów codziennie klepie kawałki kodu typu:List<Customer> allCustomers = new ArrayList<>(); for( group: customersGroups) { allCustomers.addAll(group.getCustomers()); }zamiast użyć generycznego
fold. A fold nawet nie jest jeszcze najbardziej ogólnym rozwiązaniem. Bo można to jeszcze bardziej uogólnić i używaćcata.
Tylko wtedy na twarz dostaje się pojęcia typu F-algebra, Functor itp. (w zamian za to można używać całej gamy tzw.recursion schemes).
Wychodzi na to, że aby nie pisać pierdołowatych pętli to trzeba spędzić rok z teorią kategorii, a potem jeszcze wywalić javę (czy np. kotlina) bo takie abstrakcje
w tych językach są nie do wyrażenia (sensownego). Mało komu będzie się chciało. Użyjemypatternu- czyli copy/paste tylko z mniej śmierdzącą nazwą.
Myślę że przesadzasz. Ten kod potrzebuje map i flatten ewentualnie flatMap. Czyli jeśli się nie mylę:
val allCustomers = customersGroups.flatMap(_.getCustomers)
Nie trzeba wiedzieć co to Functor żeby napisać flatMap. Nie trzeba nawet wiedzieć co to Monada mimo że właśnie się jej użyło.
BTW co to cata?
Moim zdaniem na sprawę trzeba spojrzeć znacznie szerzej:
Samo programowanie jak i branża się zmieni. Oczywiście dalej będą potrzebni wymiatacze techniczni tacy jak @jarekr000000
Potrzebni będą tak jak teraz do pisania kompilatorów i interpreterów języków.
Moim zdaniem obecne trendy na rynku doprowadzą do większego budowania oprogramowania z już gotowych klocków. Będą one przygotowane wcześniej przed programistów i dzielone na zasadzie modelu open source ewentualnie z płatnym supportem ewentualnie SaaS'a.
Samo programowanie będzie zlepianiem elementów, nie pisaniem kodu i programiści dalej będą doradcami biznesu.
Nie mówię że samo programowanie zostanie wycofane, jednak większy udział będzie miał biznes.
Co do samych pluginów i IDE to sztuczna inteligencja nauczona dużymi zbiorami danych z stack overflow oraz githuba będzie raczej podpowiadać nam przy błędach kompilacji ewentualnie interpretacji języka oraz pokazywać co w kodzie można poprawić poprzez statyczną analizę kodu np. Sonda Qube oraz Vera Code
Moim zdaniem dobrym przykładem tego jak wyglądać będzie za parę lat programowanie jest uświadomienie sobie jak wyglądało ono jeszcze w latach 90"
Moim zdaniem obecne trendy na rynku doprowadzą do większego budowania oprogramowania z już gotowych klocków. Będą
Samo programowanie będzie zlepianiem elementów, nie pisaniem kodu
@Marcin Marcin nie chce cię martwić, ale tak już jest i to od samego początku! Bo czym niby było wprowadzenie funkcji, procedur i bibliotek do języków programowania? Czym niby jest wprowadzenie frameworków i w ogóle całych gotowych komponentów (jak bazy danych, kolejki, webserwery). Kiedy ostatnio napisałeś kawałek kodu który nie składał się z takich posklejanych klocków? Umiałbyś w ogóle wyświetlić coś na ekranie albo wczytać z pliku bez użycia gotowych funkcji? ;)
I tak samo od zarania dziejów ludzie wróżyli że niedługo programistów nie będzie, bo będą na wszystko takie gotowe klocki i wystarczy je poskładać raz dwa :D Niektórzy wierzyli np. ze na podstawie diagramów UML będzie można wygenerować sobie dowolny system. Okazuje się jednak, że żeby było to mozliwe, to szczegółowość takiego diagramu niczym nie odróżnia go od kodu.
I co z tego że mamy te wszystkie "klocki" skoro cała trudność polega na tym, żeby wymyślić jak je poskładać tak, żeby rozwiązać konkretny problem. To jest zresztą przecież nic innego jak definicja "inżynierii" - wykorzystanie istniejących narzędzi i wiedzy do rozwiązywania konkretnych problemów.
Wiele sie zmieni, ale dokładnie w ten sam sposób co dotychczas -> programiści będą migrować w kierunku języków "wyższego poziomu". Kiedys przesiadali się z asemblera do C, potem jakiegoś C++ potem Javy czy C# dziś pewnie na jakiegoś Rusta, Kotlina czy Scale. Wszystko to bardziej złożone klocki
@Shalom: są programiści którzy starają się jak najwięcej "wartości dodanej" wprowadzić, pisząc na podstawie prostego diagramu kod typu: rozkładamy klocek na czynniki pierwsze w kolejnej funkcji składamy i znowu, i są szefowie którzy na to pozwalają ciesząc się jeszcze że taki skalowalny system to jest ;) więc języki wyższego poziomu wcale nie spowodują że gównokodu będzie mniejsza ilość
@Miang: Inżynieria oprogramowania to coś kompletnie innego niż inżynieria. Zakładając, że masz fabrykę balonów - musisz zaprojektować produkt, zaprojektować linie produkcyjną i strzaskać. Masz krótki etap projektowania i trwający długo i powtarzalny etap produkcji.
W programowaniu nie masz produkcji i nie masz powtarzalności. Zaczynasz od wymagań, robisz dokumentacje techniczną, dzielisz kod komponentów na klasy, metody na mniejsze metody, sprawdzasz, czy te metody robią to co chciałabyś, żeby robiły itd. Ostatecznie masz kod, który jest ostatecznym (hehe) PROJEKTEM systemu. Oczywiście można ten kod napisał "ładniej", albo paskudniej, ale sprowadza się to do logicznie spójnego (hehe) OPISU działania aplikacji. Można się oczywiście wspomagać użyciem bibliotek, frameworków, patternów i generatorów, ale inżynier mechanik też korzysta z katalogu gotowych części i nikt od niego nie oczekuje, że projektując mikser wprowadzi własny standard śrub (wyjątkiem są inżynierowie francuscy, ale to dłuższy temat). Opisywany przez ciebie przykład "Zosi Samosi", to albo ludzie z przerostem ego, albo niedouczeni i wymyślają koło na nowo, bo nie wiedzą jakie rozwiązanie zastosować.