Docker/ORM/Baza danych/Język programowania - czy to na pewno narzędzia?

Czy faktycznie takie technologie jak docker, terraform, kubernetes, orm, wszelkie frameworki i biblioteki i bazy danych można określić mianem "narzędzia"? Określnie na pewno zaporzyczone z dziedzin inżynierii bardziej "realnej", jak mechanika/elektryka/fizyka, i tam w rzeczy samej narzędzia są nieocenione - używa się ich, do czegoś. Np śrubokrętu do wkręcenia czegoś, miernika do sprawdzenia napięcia, wiertarki do zrobienia dziury. Ale po skończonym projekcie, wszystkie narzędzia mechaniczne są zabierane z powrotem przez firme która wykonała zadanie. Oczywiście pewne materiały musiały zostać użyte, jakiś cement, gips, luta, etc - owszem, to materiały. Ale narzędzia zostały zabrane. Ktoś inny, może przyjść z zupełnie innymi narzędziami i wprowadzić zmiane w mieszkaniu czy układzie. Z tej uwagi są wszechstronne, szybkie do użycia i bardzo tanie (koszt nauczenia się ich obsługi jest mały, względem tego co można nimi osiągnąć). Oczywiście, muszą spełniać pewne kryteria - płaskiego nie odkręcimy krzyżakiem; ale mamy dowolność w wyborze swojego śrubokręta lub wkrętarki.

Ale w programowaniu, rzeczy które noszą nazwę "narzędzia" nie cechują się tymi kryteriami. Kiedy "używamy" dockera do czegoś, to musimy napisać tam Dockerfile/docker-compose porobić odpowiednie obrazy, i dochodzi do sytuacji w której tak "zdockeryzowany" projekt już nie można odpalić bez dockera. Podobnie jest z wszystkimi frameworkami i bibliotekami - 99% programistów nie stosuje dependency inversion oraz odpowiednich abstrakcji (heh, interfejsów jest milion, ale dobrej abstrakcji nadal nie ma) więc raz dodany framework lub biblioteka jest na stałe przywiązana do tego projektu i nie sposób się jej pozbyć. Również korzystanie z bazy danych nas często ogranicza, bo ustawienia oraz specjalne hack często są specificzne do danej bazy danych - w dojrzałych projektach często zachodzą potrzeby zmiany silnika bazy danych, ale nie robi się tego przez zbyt dużą trudność techniczną. Dostając projekt do wykończenia, nie możemy użyć już innych narzędzi (tak jak inny pan majster mógłby), jesteśmy bardzo silnie związani z użytą technologią. Odpowiednim słowem "zbiorczym" na wszelkiego rodzaju dockery, terraformy, kubernetesy, frameworki i biblioteki to byłoby: "zależność". (Spodziewam się że wielu ludzi przywykły do myśli "dockerem można się oddzielić od systemu", więc jak docker mógłby być zależnością? :o No ale to jest po prostu inny rodzaj zależnośći - zamiast zależności od OS'a, mamy zależność od dockera - mniejsze zło). Servera również nie można nazwać narzędziem (chyba że w domyślnej konfiguracji), bo jak dodamy .htaccess do projektu to bam - kolejna zależność.

Co więc można nazwać narzędziem? Moim zdaniem coś co jest pomocne przy wytwarzaniu oprogramowania, ale powstałe w ten sposób oprogramowanie można nadal rozwijać bez jego pomocy, lub przy pomoc czegoś innego.

Przykłady moim zdaniem to:

• IDE, edytory
• shelle (jak bash, fish)
• git (bo jedyna zależność gita na projekt to jest dodanie .gitignore, czyli bardzo mało)
• kompilator (pod warunkiem że w oprogramowaniu nie ma zależności na ten kompilator, oprócz wersji)
• repozytorium (github, gitlab, bitbucket, azure - pod warunkiem że nie mamy zależności na ten cloud, np jakby spora cześć logiki była odpalana w github actions)
• klienty http (jak postman albo jakiś backuper bazy danych)
• generatory dokumentacji z kodu (pod warunkiem że nie mamy zależności na niego w kodzie, jak np swagger)
• Docker (np do postawienia bazy danych na szybko; bo w momencie jak dodajemy Dockerfile i docker-compose.yaml do projektu, to znowu to jest zależność)
• narzędzia developerskie: jak debugger i profiler
• scaffold frameworków (artisan, cargo, manage, rails)

I to by było na tyle? Chyba nic innego nie zasługuje na miano "narzędzie", bo cokolwiek innego chcemy "użyć" w projekcie, to automatycznie przywiązujemy nasz projekt do tego.

Więc pojawia się pytanie, skąd taka moda na używanie określeń takich jak tool?

Nie wiem, dla mnie narzędzia to IDE, edytory, debugery, profilery - ogólnie programy, których ja używam w celu wytwarzania oprogramowania.
Nigdy nie nazywałem bazy danych, frameworka czy biblioteki mianem narzędzia.

W kontekście globalnym można by nawet rozważyć język programowania jako narzędzie. Taki głupi przykład, tworzysz exe'ka i czy zrobisz to w C++, Python czy w innym języku to na koniec dostarczasz produkt w postaci pliku. Analogia do opisanego wykorzystania narzędzi. Jeśli weźmiemy pręt i wykorzystamy go jako dźwignia do przesunięcia czegoś to jest to narzędzie. Jeśli go zamurujemy w fundamencie to jest to typowy materiał. Jak mawiał klasyk punkt widzenia zależy od punktu siedzenia.

Dla mnie bardzo szerokie pojęcie. Narzędzie, czyli coś co ułatwia wykonanie pracy. Bez narzędzi jest to trudniejsze/bardziej czasochłonne. To, że nie potrzebujesz jakiegoś narzędzia w swojej pracy siebie, bądź używasz go bez sensu, nie implikuje, że nie jest to narzędzie i nie można tak nazywać.

Zgaduję, że ciężko znaleźć dobrą nazwę. Jeśli chodzi o orm, wszelkie frameworki i biblioteki to IMO biblioteka jest dobry terminem. Całą resztę ciężko nazwać jakoś zbiórczo. Jedyna część wspólna jaką widzę to oderwanie od naszego kodu (osobny proces/usługa w sieci) i duża "generyczność" rozwiązania (czyli to nie jest rozwiązanie skrojone pod nas)

Riddle napisał(a):

• shelle (jak bash, fish)

Chyba że aplikację akurat napiszesz w Bashu/Fishu :D to wtedy sa językami a nie toolami :P

Więc pojawia się pytanie, skąd taka moda na używanie określeń takich jak tool?

Jest język, biblioteki, frameworki. Resztę jakoś trzeba nazwać i wrzucono do wspólnego worka pod nazwą tool. To trochę jak z warzywem. Jest to jadalna część rośliny która nie jest owocem ani zbożem :D Oczywiście z wyjątkami bo po głebszym przyjrzeniu się sa jeszcze zboża rzekome i owoce pozorne. Więc prosta definicja zaczyna się jeszcze bardziej rozpadać i staje się tylko umową, konwencją historyczną. Ale życie to nie matematyka i nie mamy procyzyjnych definicji :(

BWT A framework do pisania testów też zaliczysz do tooli? Nie musi być dostarczany w ostatecznej wersji. Jeśli są to osobne testy integracyjne, E2E czy akceptacyjne to może być dostarczany do klienta. Ale chyba wtedy staje się to osobnym toolem?

Ogólnie to rozumiem co piszesz i nawet w większości się zgadzam, ale mam jedno pytanie: PO CO?

Czy to ma jakiś realny wpływ, że IDE/Dockera/język programowania nazwiesz narzędziem, biblioteką, toolchainem, framweorkiem czy zależnością? Czy w jakiś sposób to wpłynie na to, jak z nich korzystasz? Czy jak teraz ustalimy wspólną wersję, co jest narzędziem, a co nie, to nagle wszyscy uczestnicy rozmowy (oraz osoby czytające ten wątek) zaczną pisać lepszy kod?

Trochę mi to przypomina sytuację, w której jest rozmowa o samochodach/transporcie, ludzie piszą o TIR'ach i nagle jakiś przemądrzały pajac, który nie ma niczego sensownego do powiedzenia, musi wrzucić swoją mądrość że TIR to nie duże auto, ale konwencja o transporcie drogowym. OK, formalnie ma rację, ale każdy wie o co chodzi, gdy się mówi o TIR'ach. Ta uwaga nic nie wnosi do sprawy. I podobnie jest z tym wątkiem. Znaczy - nie chcę, żeby wyszło, że nazwałem Cie własnie przemądrzałym pajacem bo tak nie jest, ale totalnie nie rozumiem, po co roztrząsać tak nieistotne sprawy. Raczej niczego to nie zmieni, tylko taka czysto akademicka dyskusja - jak kiedyś "fachowcy" obliczali, ile diabłów się zmieści na łebku od szpilki :D - https://www.bryk.pl/wypracowania/pozostale/matematyka/23472-ile-diablow-miesci-sie-na-koncu-szpilki.html

O kurcze, to powinno być przeniesione do działu filozofia programowania..

Roman Mokrzan napisał(a):

O kurcze, to powinno być przeniesione do działu filozofia programowania..

Od takich dyskusji były kiedyś działy flame na forach, ale to było jeszcze przed farmami trollów (trolle zawsze były, ale kiedyś nie byli zorganizowani).

jurek1980 napisał(a):

W kontekście globalnym można by nawet rozważyć język programowania jako narzędzie. Taki głupi przykład, tworzysz exe'ka i czy zrobisz to w C++, Python czy w innym języku to na koniec dostarczasz produkt w postaci pliku. Analogia do opisanego wykorzystania narzędzi. Jeśli weźmiemy pręt i wykorzystamy go jako dźwignia do przesunięcia czegoś to jest to narzędzie. \

Niby tak, aczkolwiek ciężko znaleźć większą zależność aplikacji niż język programowania w którym jest napisana :D

jurek1980 napisał(a):

Jeśli go zamurujemy w fundamencie to jest to typowy materiał. Jak mawiał klasyk punkt widzenia zależy od punktu siedzenia.

No tak. To zależy czy technologia dodaje zależności do aplikacji czy nie. Jeśli dodaje, to raczej narzędziem nie jest tylko materiałem :D (czyt. zależnością).

KamilAdam napisał(a):

Riddle napisał(a):

• shelle (jak bash, fish)

Chyba że aplikację akurat napiszesz w Bashu/Fishu :D to wtedy sa językami a nie toolami :P

No tak, oczywiście :>

KamilAdam napisał(a):

BWT A framework do pisania testów też zaliczysz do tooli? Nie musi być dostarczany w ostatecznej wersji. Jeśli są to osobne testy integracyjne, E2E czy akceptacyjne to może być dostarczany do klienta. Ale chyba wtedy staje się to osobnym toolem?

Moim zdaniem to nie jest tool, dlatego że nie używamy go w oderwaniu od aplikacji. Jak napiszemy testy w takim jUnit, xUnit, phpUnit, to trzeba zacommitować to do kontroli wersji, i wtedy testy stają się bardziej związane z runnerem testów. Moim zdaniem runner testów to biblioteka jak każda inna. To że ma własnego executable i można go odpalać niezależnie to po prostu inny interfejs. Wszlekiego rodzaju runnery testów (e2e, unit, etc.) to moim zdaniem kolejna zależność.

cerrato napisał(a):

Czy to ma jakiś realny wpływ, że IDE/Dockera/język programowania nazwiesz narzędziem, biblioteką, toolchainem, framweorkiem czy zależnością? Czy w jakiś sposób to wpłynie na to, jak z nich korzystasz? Czy jak teraz ustalimy wspólną wersję, co jest narzędziem, a co nie, to nagle wszyscy uczestnicy rozmowy (oraz osoby czytające ten wątek) zaczną pisać lepszy kod?

Myślę że wpływa w taki sposób, że jeśli coś jest nazywane "tool"em, to łatwiej przychodzi większość codderów tego użyć - no bo przecież narzędzia są super, są fajne, szybkie, pomagają, nic nas nie kosztują.

Jak zaczniesz myśleć o czymś w kontekście zależności, to zastanowisz się dwa razy czy koszt dodania jej do projektu jest tego warty. Nawet jak nazwiesz cos "fremework" (zamiast biblioteka), to ludzie się zastanowią dwa razy czy to dodać.

Na stronie dockera teraz jest napis:

The most-loved Tool in Stack Overflow’s 2022 Developer Survey.

zmień go na

The most-loved runtime dependency in Stack Overflow’s 2022 Developer Survey.

I zobacz jak to wpłynie na postrzeganie tego.

I zobacz jak to wpłynie na postrzeganie tego

Myślę, że za wiele to nie zmieni. Jak ktoś potrzebuje Dockera to z niego skorzysta, nawet jakbyś na ich stronie napisał Docker - fucking useless doodle without dependencies ;) A jak ktoś rozważa skorzystanie z niego, to raczej nie w oparciu o jakieś jedno zdanie umieszczone na ich stronie. Zresztą - jakby taki się trafił to naprawdę ciężko serio traktować kogoś (i się sugerować jego opinią), kto podejmuje decyzje projektowe w oparciu o jednozdaniowe hasło reklamowe na stronie projektu :P

Według mnie to w tej całej filozofii chodzi chyba o to że Twój kod/konfiguracja a nawet ogólniej zestawy instrukcji to właśnie jest Twoja apka a cała reszta na której to odpalasz i z których korzystasz to toole, które de facto mogą zastępować instrukcje ale nie ważne gdzie, kto i kiedy to odpali to jeśli odpali to z "tą" konfiguracja to będzie daną aplikacja której podstawą są Twoje instrukcje ale przy okazji korzystające z czegos.. z tooli. Chyba zawiłe trochę to opisałem ale chyba wiecie co miałem na myśli xD

Na moje to minąłeś się z powołaniem. Trzeba było zostać botanikiem, biegać gdzieś po stepie i klasyfikować roślinki.

Tak jak sam zauważyłeś - zależy.

Nie słyszałem aby ktoś nazywał bazę danych narzędziem, bo prędzej jest komponentem aplikacji, ale jeżeli ktoś chciałby przemielić jakąś dużą CSVkę i zdecydowałby się wrzucić ją do MSSQLa, to jak najbardziej byłaby narzędziem.

Tak samo z Dockerem - jeżeli używasz go do postawienia sobie bazki na potrzeby local developmentu, to jak najbardziej jest narzędziem, ale jeżeli do wdrożeń, to już jest komponentem całego twojego procesu.

Język programowania również, bo możesz potrzebować coś sobie policzyć, napiszesz kod (nawet w kompilatorze online) i go porzucisz, bo chciałeś tylko wynik.

Narzędziami są IDE, komputer, system operacyjny, na którym pracuje wykonawca.
Framework, biblioteka, baza danych itp to tzw. półprodukty.
Jak spawacz montuje rury to używa rur, półproduktu (biblioteki) a do ich pospawania używa spawarki (IDE).

cerrato napisał(a):

Ogólnie to rozumiem co piszesz i nawet w większości się zgadzam, ale mam jedno pytanie: PO CO?

Mi się wydaję, że ustandaryzowanie nazewnictwa, określeń, znaczeń jest bardzo ważne.
Im bardziej wszyscy mówimy tym samym językiem, tak samo rozumiemy oznaczenia tym szybciej nasze dyskusje mogą wejść na bardziej zaawansowany 'poziom'.

Zapytaj się na forum, kto co rozumie przez komponent, obiekt, klasę.
Zapytaj się @Riddle co to znaczy programowanie OOP i zapytaj kogokolwiek innego - niby każdy myśli o tym samym, ale nie do końca :)

@MuadibAtrides: Oczywiście, wspólne rozumienie jakiegoś słowa jest istotne w komunikacji. Bo trudno się efektywnie komunikować zdaniami "Ej weź zmień to co tam masz na ten drugi wzorzec projektowy". Tylko pytanie, czy sytuacja w której ktoś nazywa młotek narzędziem, a ktoś inny przyrządem wprowadza takie trudności komunikacyjne.

Jak wylejesz beton pod posadzkę i wrzucisz do niego śrubokręt to śrubokręt dalej będzie narzędziem, mimo że będzie pełnił rolę trochę inną

@ToTomki: no nie zgodę się. To już raczej nie będzie śrubokręt (czyli narzędzie), ale element zbrojenia betonu wykonany z podłużnego kawałka metalu zakończonego gumowanym owalnym kształtem ;)

Ciekawa rzecz, ale czy ma jakieś zastosowanie praktyczne?

loza_prowizoryczna napisał(a):

Ciekawa rzecz, ale czy ma jakieś zastosowanie praktyczne?

Celem jest mniejsza skłonność do godzenia się na zależności; tylko dlatego że określimy je bardziej przyjemnym terminem.

Riddle napisał(a):

Celem jest mniejsza skłonność do godzenia się na zależności;

Godzenie się na zależności to przeszłość. Wiesz tak jak relacja master-slave.

tylko dlatego że określimy je bardziej przyjemnym terminem.

Powiedziałbym raczej że hierarchicznie neutralnym. Jak np. stosunek. Dlatego pytanie OPa jest źle sformułowane. Powinno brzmieć jakie są ich stosunki + ew. jakie są ich stosunki do stosunków po stosunku.

loza_prowizoryczna napisał(a):

Riddle napisał(a):

Celem jest mniejsza skłonność do godzenia się na zależności;

Godzenie się na zależności to przeszłość. Wiesz tak jak relacja master-slave.

No jak widać nie taka przeszłość, bo powstają nowe projekty które od startu są przywiązane do wielu zależności.

Riddle napisał(a):

No jak widać nie taka przeszłość, bo powstają nowe projekty które od startu są przywiązane do wielu zależności.

Kreatywna rola stosunków (unikajmy tego wartościującego określenia zależności). Weź np. taki stosunek - ja zadłużam się w banku na milion, pożyczam ci na procent ten milion, ty masz kumpla który na gwałt potrzebuje milion bo ma zapadalność kredytu na wczoraj. Bank jest szczęśliwy bo ma milion, kumpel kumpla jest szczęśliwy bo go nie zlicytowali, my jesteśmy szczęśliwi bo mogliśmy pomóc i mamy z tego procent.

A dług rośnie.

Bycie narzędziem nie wyklucza bycia zależnością.

nalik napisał(a):

Bycie narzędziem nie wyklucza bycia zależnością.

No właśnie moim zdaniem trochę wyklucza.

1. Używąjc Linuka jako systemu operacyjnego napisałem program, który robi syscalle linuksowe. Uruchamiam tą aplikację na Linuksie. Czy Linuks jest narzędziem czy zależnością? A może zależy od kontekstu?
2. Uruchamiam basha przy pomocy dockera, bo mogę. Czy to zależność basha? Napisałem apliakcję, która bezpośrednio korzysta z docker.socket. Uruchamiam ją przy pomocy dockera, montując docker.socket. Czy docker to narzędzie czy zależność dla tej aplikacji?

Riddle napisał(a):

nalik napisał(a):

Bycie narzędziem nie wyklucza bycia zależnością.

No właśnie moim zdaniem trochę wyklucza.

No to Twój problem. Ja osobiście nie uważam, że się wyklucza, bo część narzędzi jest zależnościami (np. język czy DB), a inne nie (np. edytor tekstu czy używana implementacja grep).

hauleth napisał(a):

No to Twój problem. Ja osobiście nie uważam, że się wyklucza, bo część narzędzi jest zależnościami (np. język czy DB),

No właśnie o tym jest cały wątek.

Chodzi o skłonność i bezkrytyczność w dodawaniu sobie zależności do aplikacji, dlatego że jedne zalezności nazywamy narzędziem a inne nie.