On 30/08/2021 11:53, Maciek Godek wrote:
>>> Ludzie generalnie mają swoje przyzwyczajenia. To one są w ostatecznym rachunku
rozstrzygające
>>> dla tego, czy ktoś będzie używał, gita, svna czy zipa; czy wybierze notatnik,
notepad++, emacsa,
>>> vima, VS Code czy jakieś rozbudowane IDE.
>> Nie. Nie wybierzesz notatnika, jeśli potrzebujez debugu.
> Faktycznie. Wtedy użyjesz debuggera.
> Podobnie, notatnik nie skompiluje ci Twojego kodu źródłowego. Do tego jest
kompilator.
> Ale po co tracić czas na równie błyskotliwe obserwacje?

Aby wypunktować głupie stwierdzenie "ludzie uzyją tego do czego są
przyzwyczajeni".

Mądrzy ludzie użyją tego, co lepiej się sprawdzi. Liczę na to, że o
głupich tu nie rozmawiamy.

Akurat Notatnik nie sprawdza się w *niczym* lepiej, lub są to przesłanki
poza tematem programowania, wymyślane na siłę.

>> Nie przyzyczajenia wybierają narzędzia, Potrzeby i dopiero drugorzędnie
>> przyzwyczajenia.
> Dokładnie. Więc jeżeli ktoś używa Notatnika zamiast Atoma, to najwidoczniej
Notatnik spełnia jego potrzeby.

Musi mieć zerowe potrzeby, wtedy Notatnik jest prawidłowym wyborem.

Ludzie parający się programowaniem zawodowo lub hobbystycznie miewają
potrzeby większe od zera. Zaczynając od kolorowania składni, na przykład.

>> Jesli jest inaczej - nie nadajesz się do zagadnienia bo dobiersz
>> narzędzia z klucza religijnego a nie pragmatycznego.
> Stwierdzenie trochę od czapy. Jeżeli Twoje narzędzia okażą się skuteczne, to to
były "wystarczająco dobre narzędzia".

Nie.

Wystarczająco dobre narzędzia prawie nigdy nie bywają optymalne.

Skutecznośc nie jest miarą optymalności.

Można skutecznie dojśc na piechotę do Bratysławy, ale można optymalnie
skorzytać z transportu mechanicznego.

Skuteczność ma sens tylko pod warunkiem że jest biska optymalnej.
Inaczej jesteś jak ten hindus który wydłubał basen patykiem. Fajnie,
tylko niekoniecznie ma to zastosowanie komercyjne.

> W ostatecznym rozrachunku liczy się to, czy rozwiązałeś problem.

Nie tylko. Liczy się tez jakim kosztem. Nie chcesz prowadzić firmy gdzie
dev jest na notatniku, tak samo jak nie chcesz używać edytora do pisania
listy zakupów w celu napisania jakiegoś domowego exampla w pythonie. To
złe narzędzie. To sie nawet nazywa: golden hammer. Tylko że w tym
wypadku to jest golden stick i to z tektury.

> W posiadaniu przyzwyczajneń nie ma nic religinego. Natomiast atakowanie cudzych
narzędzi bez jakiegokolwiek kontekstu to zwykła forma prymitywnej mentalności
plemiennej.

Ajeż kontekst jest. Nawet go wyjasniłem: narzędzie dla programistów
posiadają ficzery dla programistów.

Notatnik nie ma żadnych ficzerów dla programitów. To jak byś powiedział,
że ktoś atakuje Cie za to że używasz wiadra zamiast betoniarki, bo takie
masz przyzwyczajenia. To je zmień. Wiadro jest niewydajne. Jeśli
będziesz używać wiadra, to nie dziw się, że ludzie używajacy betoriarek
będą rechotać na samą myśl o takiej organizacji pracy. Możesz być
wiadranym mistrzem betonowania. Dalej to bez sensu w profesjonalnych i
amatorskich zastosowaniach.

>> Atom czy inny wypasiony edytor sformatuje Ci kod w pythonie
>> automatycznie.
> Akurat w Pythonie nie da się sformatować kodu automatycznie.

Zbawne. Bo mi formatuje. Może mam innego pythona. Naciskam enter i
edytor wie ile wyciąć zrobić. Magia. Czasami nie wie, ale naciśniecie 1
raz backspace na kilka linijek jest lepsze niż 10x tab co każdą.

> Notatnik nie. Efektem czego będziesz napierniczał
>> spacją/tabulacją w notatniku znacznie częsciej, tracąc czas na
>> ascii-art. W domu rób co chcesz, choć to głupie. W przypadku firmy -
>> nie. Tam napierniczanie spacją kosztuje konkretne pieniądze.
> Ani napierniczanie spacją, ani automatyczne wcinanie, nie jest czymś, co by
interesowało jakąkolwiek firmę.

Wiec nigdy nie widziałeś na czym polega wydajnosc pracy w firmach.
Interesuje ich jak szybko jesteś w stanie pracować. Z tych samych
powodów ekipa remontowa dostaje od szefa wiertarki a nie patyki do
dłubania w betonie, choć oba narzędzia w gruncie rzeczy na końcu
uzyskają ten sam efekt.

> Firmę interesuje to, czy pracownik w określonym czasie wywiązuje się ze swoich
obowiązków.

Nie. Firmę interesuje jak zwiększyć wydajność pracy. Praca z Notatnikiem
jest biegunowo odległa od tego celu. Jeśli nie zmieniasz narzędzi na
wydajniejsze - odpadasz. ta zasada obowiązuje nawet amatora programistę.

>> Masz ciekawe podejście: aby uzyskać duży zysk trzeba coś robić i to jest
>> straszliwy problem "bo przyzwyczajenia". Serio, myslisz że dobry
>> programista to jest ten co ma "przyzwyczajenia" i preferuje je nad
>> rozwiązania optymalne?
> Jaki "duży zysk"? Postawienie serwera svn to "duży zysk"?

W porównaniu z ZIPami o które tu głównie cała dyskusja się rozbija. A
teraz przyplątał się Notatnik. Czy jutro dowiem się, że najlepszym
językiem do wszystkiego jest assembler a za maszynę styknie coś na Z80?
To jakiś konkurs w celu ośmieszenia zawodu programisty?

> W przypadku gita nie muszę stawiać żadnego serwera.

Podobnie jak w przyapdku SVN. Serwer natomiast pojawił się jako coś, co
miało pokazać że *nawet* jesli go postawisz, to koszt tej operacji jest
śmiesznie mały w porównaniu z zyskiem. Czy serwer czy nie, argument o
tym że to trudne, jest po prostu żałosny.

>> Ilość gówna jest adekwatna do poziomu dyskutowania z okolic "svn do do
>> bani bo mi się długo branche robiły" i tym podobe debilizmy. Jak się nie
>> zareaguje na to, to potem zostaje, przysycha i na koniec ludzie czytaja
>> w necie że git dobry, svn nie bo jakiś ktoś na usenecie tak powiedział i
>> nikt go nie kopnął w tyłek, odruchowo, za bredzenie.
> O rety, i co wtedy? I wtedy ludzie zaczynają myśleć, że "git jest lepszy od svn"?

Tak. Możesz sobie zobaczyć taki efekt włanie po tym wątku. ktos gdzieś
coś przeczytał, źle użył i urosło uprzedzenie w postaci wypowiedzi
rozminiętych z prawdą. Tego typu brednie należy przecinać zanim wyrosną
na legendy z którymi nie da się już wlaczyć.

do góry

On 30/08/2021 11:51, Mateusz Viste wrote:
>>> Pokrótce obejrzałem. Pierwszy szok: rpm o rozmiarze 194 MiB.
>> To słaby argument. Atom wstaje szybko i tylko to się liczy.
> To nie był żaden argument :)

Wobec tego, skoro to nie argument, to co Ci przeszkadza?

> To był powód, dla którego *mi* dane rozwiązanie nie odpowiada.

Czyli argument?

Ale nie przedstawiłeś *racjonalnego* agrumentu przeciw. Nie bo nie. Ja
tego argumentem nie nazywam.

> No to ja się pytam: na kij mi to, skoro i tak z 90% rzeczy nie
> skorzystam?

Bo pozostałych 10% nie ma w notatniku.

>> Integracje z VCS są rzeczą oczywistą w edytorach dla programistów.
>> Spróbuj znaleźc jakiś bez, przeznaczony własnie dla programistów.
> Proszę: kwrite. Pewno powiesz, że to nie edytor "dla programistów"...
> Ale chyba jednak jest, bo po co nie-programiście podświetlanie składni
> dla C, Java, CSS, itp?

Podświetla składnie xmla? Czy kto piszący xmla to programita?

Ogólnie podświetlanie składni jest ficzerem używanym przez programistów,
ale niekoniecznie tylko dla nich.

>> Szanse niewielkie. Po co komu edytor bez VCS?
> Edytor do pisania. VCS do VCS-owania. Ja VCS-uję sobie z linii poleceń.

I widzisz czytelne diffy? Czy masz już w mózgu parser united diffa?
Widziałeś jak się pracuje z Tortoise/Rabbit lub ze zintegrowanym VCS w
edytor?

Ja nie potrafie znaleźc argumentów przeciwko taiej integracji.
Najzwyczajniej, dzielenie przez zero.

>> Zauważ, że Atom to obecnie ulubiony edytor domowych hackerów.
> To ci sami, co zachwycają się gitem? Ech, młodzież...

Ta młodzież potrafi pisać szybciej i skuteczniej, niż stare dziadki, jak
ja. Głównie dlatego że nie przejmują się idityzmami typu
"przyzwyczajenia" tylko szukają rozwiązań optymalnych.

do góry

2021-08-30 o 12:29 +0200, heby napisał:
> On 30/08/2021 11:51, Mateusz Viste wrote:
> >>> Pokrótce obejrzałem. Pierwszy szok: rpm o rozmiarze 194 MiB.
> >> To słaby argument. Atom wstaje szybko i tylko to się liczy.
> > To nie był żaden argument :)
>
> Wobec tego, skoro to nie argument, to co Ci przeszkadza?

Rozmiar nie jest argumentem. Argumentem jest ból brzucha, który rozmiar
u mnie powoduje. I on mi przeszkadza. Naprawdę.

> Ale nie przedstawiłeś *racjonalnego* agrumentu przeciw.

Przecież podałem: widząc edytor tekstowy o rozmiarze 400 MiB ściska mnie
pod żołądkiem. A ja wolę żyć bez bólu, niż z bólem. Czy to
wystarczająco racjonalne?

> > podświetlanie składni dla C, Java, CSS, itp?
>
> Podświetla składnie xmla? Czy kto piszący xmla to programita?

Nie wiem, gdzie wyczytałeś o XMLu... Przecież wyraźnie pisałem o czymś
innym. Tutaj dwa konkretne przykłady jak to wygląda, bo masz zdaje się
nierzeczywiste wyobrażenia:

https://imgpile.com/images/N3Qniw.png
https://imgpile.com/images/N3Q4Ul.png

Podświetlanie składni jest.
Auto-indentacja jest (brak "napierniczania spacji"!).
Search i search & replace są.
Konfigurowalna szerokość tabulacji jest.
Auto-save jest.

Nic więcej mi nie potrzeba. Jest nawet kilka dodatkowych, potencjalnie
fajnych rzeczy, choć z nich nie korzystam: zawijanie kodu, tworzenie
zakładek w kodzie czy też podpowiadanie nazw zmiennych.

> I widzisz czytelne diffy? Czy masz już w mózgu parser united diffa?
> Widziałeś jak się pracuje z Tortoise/Rabbit lub ze zintegrowanym VCS
> w edytor?

Tak, widziałem. Gdybym całe dnie spędzał na oglądaniu diffów to może
używałbym jakiegoś upiękczacza, ale analiza diffów to może z 5% mojego
czasu. svn diff jest dla mnie jak najbardziej czytelny, i zupełnie
wystarczający. A wygląda tak:

svn diff unchtest.c
Index: unchtest.c
====================================================
===============
--- unchtest.c (revision 339)
+++ unchtest.c (working copy)
@@ -80,7 +80,8 @@
int decodedbytes;
unsigned char buffer[4096];

- bytes = min((rand() % 256) + 1, file_chunk_len - bytesprocessed);
+ bytes = (rand() % 256) + 1;
+ if (bytes > file_chunk_len - bytesprocessed) {
+ bytes = file_chunk_len - bytesprocessed;
+ }
printf("processing %4zu bytes of chunked data", bytes);
memcpy(buffer, file_chunked + bytesprocessed, bytes);

Ja to czytam bez problemu, nie potrzeba mi żadnych fikuśnych kolorków.
A gdybym *naprawdę* potrzebował zastanowić się głęboko nad jakimś
diffem, to po prostu wrzuciłbym go do pliku i otworzył domyślną,
systemową diff-wyświetlarką (kompare).

Mateusz

do góry

On 30/08/2021 13:20, Mateusz Viste wrote:
>>>>> Pokrótce obejrzałem. Pierwszy szok: rpm o rozmiarze 194 MiB.
>>>> To słaby argument. Atom wstaje szybko i tylko to się liczy.
>>> To nie był żaden argument :)
>> Wobec tego, skoro to nie argument, to co Ci przeszkadza?
> Rozmiar nie jest argumentem. Argumentem jest ból brzucha, który rozmiar
> u mnie powoduje. I on mi przeszkadza. Naprawdę.

Rozumiem. Czyli dyskusja bez sensu, nie masz argumentacji racjonalnej.

> Przecież podałem: widząc edytor tekstowy o rozmiarze 400 MiB ściska mnie
> pod żołądkiem. A ja wolę żyć bez bólu, niż z bólem. Czy to
> wystarczająco racjonalne?

Nie, to ani troche racjonalne. Rozmiar współczesnego software jest
wiekszy niż w czasach Atari. Bo i mozliwości większe. Dam przykład: do
pythona jest autouzupełnianie wspomagane AI. Ile GB poświęcisz na
ficzer, któy kilkukrotnie przyspiesza pisanie kodu? Gdzie jest granica
za którą boli brzuszek? Może to ból fantomowy?

Dlaczego śladowy rozmiar na dysku jest argumentem? Rozmawiamy o
rozmiarze będacym promilem obecnej pojemnosci komputera z hipermerketu
do oglądania pono. To dużo?

> Podświetlanie składni jest.
> Auto-indentacja jest (brak "napierniczania spacji"!).
> Search i search & replace są.
> Konfigurowalna szerokość tabulacji jest.
> Auto-save jest.

Wniosek: to nie notatnik.

> Nic więcej mi nie potrzeba.

Wydaje Ci się. Najzywczajniej nie miałeś kontaktu z narzędziami takimi
jak Atom, dlatego nie widzisz przestrzeni do rowijania się.

Pocieszę Cię: ja tez nie używam Atmoma. Ale używam np. Visual Studio.

> Jest nawet kilka dodatkowych, potencjalnie
> fajnych rzeczy, choć z nich nie korzystam: zawijanie kodu, tworzenie
> zakładek w kodzie czy też podpowiadanie nazw zmiennych.

Więc to nie jest notatnik. Skąd tu się wziął notatnik w tej dyskusji?

>> I widzisz czytelne diffy? Czy masz już w mózgu parser united diffa?
>> Widziałeś jak się pracuje z Tortoise/Rabbit lub ze zintegrowanym VCS
>> w edytor?
> Tak, widziałem. Gdybym całe dnie spędzał na oglądaniu diffów to może
> używałbym jakiegoś upiękczacza, ale analiza diffów to może z 5% mojego
> czasu. svn diff jest dla mnie jak najbardziej czytelny, i zupełnie
> wystarczający. A wygląda tak:
>
> svn diff unchtest.c
> Index: unchtest.c
> ====================================================
===============
> --- unchtest.c (revision 339)
> +++ unchtest.c (working copy)
> @@ -80,7 +80,8 @@
> int decodedbytes;
> unsigned char buffer[4096];
>
> - bytes = min((rand() % 256) + 1, file_chunk_len - bytesprocessed);
> + bytes = (rand() % 256) + 1;
> + if (bytes > file_chunk_len - bytesprocessed) {
> + bytes = file_chunk_len - bytesprocessed;
> + }
> printf("processing %4zu bytes of chunked data", bytes);
> memcpy(buffer, file_chunked + bytesprocessed, bytes);
>
> Ja to czytam bez problemu, nie potrzeba mi żadnych fikuśnych kolorków.

Bo oto trywialny diff. Dodałeś w nim linijki.

Teraz zrób to samo dla difa w którym zmieniłeś 1 znak w 100 znakowej
linijce.

Jak wiem, że grunt w dyskusji to dobierać przykłady podpierajace własne
tezy, wiec sie nie dziwie, że wybrałeś przykład diffa czytelnego dla
ksiegowej.

> A gdybym *naprawdę* potrzebował zastanowić się głęboko nad jakimś
> diffem, to po prostu wrzuciłbym go do pliku i otworzył domyślną,
> systemową diff-wyświetlarką (kompare).

Co porządy edytor IDE może zrobić automatycznie, bez *dodatkowej*
czynności. I dużo, dużo więcej.

do góry

On 30/08/2021 13:20, Mateusz Viste wrote:
> Przecież podałem: widząc edytor tekstowy o rozmiarze 400 MiB ściska mnie
> pod żołądkiem.

$ apt-get install kwrite
[...] After this operation, 212 MB of additional disk space will be
used. [...]

To powoduje, dla odmiany, ból watroby?

do góry

2021-08-30 o 13:30 +0200, heby napisał:
> Wniosek: to nie notatnik.

Przyznam, że takiego obrotu dyskusji się nie spodziewałem.

> Wydaje Ci się. Najzywczajniej nie miałeś kontaktu z narzędziami
> takimi jak Atom, dlatego nie widzisz przestrzeni do rowijania się.

Miałem kontakt z różnymi narzędziami - m.in w ramach dobierania
propozycji dla moich zespołów programistów. Jeśli *o mnie* chodzi to
nie odkryłem nic co odpowiadałoby mi bardziej niż notatnik. Ok, nie
notatnik, skoro nie uznajesz takiej terminologii - nazwijmy go zatem
"Domyślnym, podstawowym edytorem tekstu w KDE". :)
Większość osób wybrało wówczas code::blocks na stosownej ilości ekranów
("bo widać wszystkie pliki od razu", "bo daje fajne podpowiedzi", "bo
integracja z svn", itp...). Ja zostałem z notatnikiem i laptopem 15".

Testowałem również kilka "edytorów dla programistów", jednak te zawsze
okazywały się *dla mnie* zbyt wyszukane. Atoma nie testowałem, być może
nie istniał 15 lat temu.

> Więc to nie jest notatnik. Skąd tu się wziął notatnik w tej dyskusji?

Mój błąd, wybacz. Chodziło mi o "podstawowy edytor tekstowy pełniący
rolę domyślnego notatnika w KDE". Wbrew tej ironii muszę jednak przyznać
Ci rację - jego opis w KDE jasno wskazuje, że od początku miał być
czymś więcej.

"KWrite is more than a text editor. It is meant to be a programmer's
editor, and could be considered as at least a partial alternative to
more powerful editors."

> Co porządy edytor IDE może zrobić automatycznie, bez *dodatkowej*
> czynności. I dużo, dużo więcej.

Może i porządny, skoro tak go zachwalasz - ale 400 MiB?? To jest
przecież 290 dyskietek! Nie poświęcę tylu dyskietek dla funkcji, z
której skorzystam *może* raz na kilka lat. Nie nie, zostanę jednak z
moim notat- tfu, domyślnym edytorem tekstu KDE.

Mateusz

do góry

On 30/08/2021 14:21, Mateusz Viste wrote:
>> Wniosek: to nie notatnik.
> Przyznam, że takiego obrotu dyskusji się nie spodziewałem.

Czego się spodziewałes? Używasz notatnika z ficzerami do programowania.

>> Więc to nie jest notatnik. Skąd tu się wziął notatnik w tej dyskusji?
> Mój błąd, wybacz. Chodziło mi o "podstawowy edytor tekstowy pełniący
> rolę domyślnego notatnika w KDE". Wbrew tej ironii muszę jednak przyznać
> Ci rację - jego opis w KDE jasno wskazuje, że od początku miał być
> czymś więcej.
> "KWrite is more than a text editor. It is meant to be a programmer's
> editor, and could be considered as at least a partial alternative to
> more powerful editors."

Wiec to nie notatnik. Teraz wyobraź sobie niedzielnego studenta, który
czyta ten usenet spijajac mądrość prosto z kabla ethernetowego i
dowiaduje się że *doświadczeni* wyjadacze używają ... notatnika do
pisania kodu.

Notepad.exe? A to ja mam!

>> Co porządy edytor IDE może zrobić automatycznie, bez *dodatkowej*
>> czynności. I dużo, dużo więcej.
> Może i porządny, skoro tak go zachwalasz - ale 400 MiB??

kwrite to ponad 200MiB.

> To jest
> przecież 290 dyskietek!

A ile kaset do Atari w normalu?

> Nie poświęcę tylu dyskietek dla funkcji, z
> której skorzystam *może* raz na kilka lat. Nie nie, zostanę jednak z
> moim notat- tfu, domyślnym edytorem tekstu KDE.

O ile masz KDE. Od razu podpowiem: mało kto ma KDE.

do góry

2021-08-30 o 13:42 +0200, heby napisał:
> On 30/08/2021 13:20, Mateusz Viste wrote:
> > Przecież podałem: widząc edytor tekstowy o rozmiarze 400 MiB ściska
> > mnie pod żołądkiem.
>
> $ apt-get install kwrite
> [...] After this operation, 212 MB of additional disk space will be
> used. [...]
>
> To powoduje, dla odmiany, ból watroby?

No wiesz, dla kogoś kto nie ma Linuksa to w ogóle będzie kosmiczny
rozmiar, bo wyjdzie że musi doinstalować kilka GB rzeczy wszelakich :)

Najwyraźniej nie masz KDE, i package manager wlicza w te 212 MB
wszelkie jego niezbędne pliki. Sama aplikacja (kwrite) zajmuje jakieś
300 KiB. Być może Gnome ma jakiś odpowiednik, nie wiem. Ja "od zawsze"
działam pod KDE.

Mateusz

do góry

poniedziałek, 30 sierpnia 2021 o 14:39:04 UTC+2 heby napisał(a):

> Wiec to nie notatnik. Teraz wyobraź sobie niedzielnego studenta, który
> czyta ten usenet spijajac mądrość prosto z kabla ethernetowego i
> dowiaduje się że *doświadczeni* wyjadacze używają ... notatnika do
> pisania kodu.
>
> Notepad.exe? A to ja mam!

Świetnie. Wyobraziłem sobie.
I co dalej?

do góry

2021-08-30 o 14:39 +0200, heby napisał:
> O ile masz KDE. Od razu podpowiem: mało kto ma KDE.

W sensie, że mało kto ma Linuksa? Nie wiem, nie prowadziłem badań, ale
wśród programistów to chyba dość popularna opcja. A wśród Linuksowców
KDE jest mainstreamowy - a przynajmniej był 20 lat temu, kiedy zacząłem
go używać. Zmieniło się coś?

Mateusz

do góry