HOVD 2023 - Kedvenc programfejlesztést segítő eszköz

HUP

  Itt a HUP Olvasók Választása Díj 2023 szavazás. Az idei HOVD immár a tizennyolcadik a sorban.

  A HOVD 2023-on minden HUP olvasó szavazhat. A HOVD 2023 választás ideje - két hónap - alatt a 20 kategóriában állított jelöltekre lehet majd szavazni.

  Szavazz az alábbi kategóriákban! Kedvenc ...

atom
2% (16 szavazat)
chatgpt
5% (45 szavazat)
eclipse és ráépülő környezetek (aptana, zend)
4% (34 szavazat)
gedit, geany, anjuta, kate
5% (47 szavazat)
intellij idea, phpstorm, webstorm, android studio (jetbrains termékek)
22% (199 szavazat)
netbeans
2% (20 szavazat)
qt creator
2% (20 szavazat)
sublime text
3% (28 szavazat)
visual studio
9% (78 szavazat)
vi, vim, emacs, nano, ed, ne, joe, mcedit (konzolos text editorok)
20% (186 szavazat)
visual studio code
26% (235 szavazat)
Összes szavazat: 908

Ir a kododhoz unit teszteket, megmondja hol van bug a kododban vagy megirja helyetted 0-rol ha kelloen pontosan specifikalod.

Youtube-on egyik fickonak az volt a kihivasa, hogy sajat kod irasa es sajat kepek rajzolasa nelkul, csak AI-vel el tud-e kesziteni egy Flappy Bird-ot. A kodot a Unityhez a ChatCPT irta, a grafikat is valami generativ AI keszitette (Dall-e/Midjourney/Stable diffusion kozul valamelyik).

A strange game. The only winning move is not to play. How about a nice game of chess?

Ir a kododhoz unit teszteket

Nyöah. Mármint van a chatgpt-nek hasznos segítsége, én is használtam már, leírtam neki, hogy mit szeretnék megvalósítani, és adott ötleteket, hogy milyen algoritmusok, függvények, libek lehetnek hasznosak a célhoz.

De attól kíméljen meg az ég, hogy a unit teszteket generálja... Aztán ~5 év hónap múlva, az első change-nél meg vakarhatjuk a fejünket, hogy a kód azért failel, mert tényleg specifikációt sértett, vagy csak a chatgpt talált valami implementation specific dolgot, ami senkit nem zavar, ha megváltozik.

Pl.: ha jól emlékszem, a Javas HashMap-eknek elég sokáig prediktálható iterációs sorrendje volt, míg a javadoc-ja sehol nem állította ezt. Ha erre olyan teszt lett volna generálva, ami elvárja a sorrendet, akkor az a teszt onnantól nem segít, hanem hátráltat, hiszen fals-pozitív failing test van benne.

MINDENT amit csinal ellenorizned kell. Ez fuggetlen attol, hogy csak otletelesre hasznalod, vagy eles kodhoz. Egyszeruen ilyen a mukodese, hallucinal, meg benez dolgokat.

Meg igy is segitseg, mert olyan sebesseggel nem irsz kodot, ahogy o.

A strange game. The only winning move is not to play. How about a nice game of chess?

A chatgpt/copilot/stb egy alsó-középkategóriás junior fejlesztő. Ennek megfelelően jól be tudod lőni, hogy mit érdemes rábízni, és mit nem. Vakon megbízni benne kb. azzal ekvivalens, hogy review nélkül elfogadod a junior kolléga PR-ját. 

az első change-nél meg vakarhatjuk a fejünket, hogy a kód azért failel, mert tényleg specifikációt sértett, vagy csak a chatgpt talált valami implementation specific dolgot, ami senkit nem zavar, ha megváltozik

Számtalanszor láttam, hogy valami implementation-specific mellékhatásra építettek egy projektben. Ez nem ChatGPT-specifikus probléma. Nagyjából 10 éve fizetnek azért, hogy kódot írjak, vagy másokat segítsek kódot írni, és 10 éve pont ugyanitt tartottunk, csak akkor éppen valami WCF-bugra épült egy kritikus rendszerünk. A bugot patchelték, a rendszer beszart, a problémát pedig rátoltuk a ChatGPT-re, hogy mekkora hülye ez, hiszen potenciálisan flaky tesztet írhat. :)

A chatgpt/copilot/stb egy alsó-középkategóriás junior fejlesztő.

Ahogy egy középkategóriás junior fejlesztőt sem ültetünk le prod kód elé, hogy „na öcsém, itt a lefejlesztett feature, írj rá kódot, mert az majd hasznos lesz”, úgy szerintem a chatgpt elé odaülő „gyűlölök-tesztet-írni-írja-meg-a-gép senior” is egy rossz irány.

Tesztet a prod kóddal együtt írunk. Pont. Esetleg, ha nagyon ezen a vonalon akarjuk kettébontani (valaki/valami írja a prod kódot, valaki más pedig a tesztet), akkor az alsó-középkategóriás junior fejlesztő írja a prod kódot, és a tapasztaltabb ember a tesztet rá. De ez az egész, más írjon prod és más teszt kódot egy tévút szerintem, a chatgpt-vel generáltassunk tesztet pedig mégtévútabb.

Lásd lejjebb: szerintem van ezeknek az eszközöknek hasznos use-case-e, lehet használni tökjó dolgokra, de az én lusta vagyok valamit megírni, ezért generálja le, majd alaposan átnézem (lol) nem ez.

A chatgpt Copilot nekem tipikusan az ilyen scaffolding jellegű favágást váltja ki. És jól váltja ki. Nagyjából annyira jól, mint amikor melóban az egyszerűbb unit tesztek írását odaadtuk a gyakornoknak, mert egyrészt abból is tanulta a rendszer működését, másrészt az volt az, amit meg tudott csinálni. Szerintem senki (értelmes) ember nem beszél arról, hogy a ChatGPT-nek odaadod a feladatot, és abból prod kód születik.

De jobbat mondok, a csapat legseniorabb emberének a kódját sem szokás prodba tenni, ugyanazokon a folyamatokon kell átmennie (unit test, regression test, statikus analízis, teszt buildek, peer review, stb.), mint a nullkilométeres juniornak.

lehet használni tökjó dolgokra, de az én lusta vagyok valamit megírni, ezért generálja le, majd alaposan átnézem (lol) nem ez.

Nem értünk egyet, szerintem elsősorban pont erre jó. Vagy legalábbis nem igazán találtam neki olyan use case-t, amiben jobb lenne. Már eleve a működési modellje (LLM) predesztinálja, hogy favágásra lesz főleg alkalmas. :)

Legaktuálisabb példám, egy soktáblás, code-first Entity Framework modellre kellett repository patternt csinálnom, ez régen úgy nézett volna ki, hogy az összes retkes entity-re meg kellett volna írni a kódot, copilottal meg gyakorlatilag a tabot kellett nyomkodnom. Nyilván a tab nyomkodása után elolvastam, és ellenőriztem az outputot, de ha nem tettem volna, akkor is fennakad a PR merge előtt.

hogy favágásra lesz főleg alkalmas

Ebben nagyrészt egyetértünk. Szerintem abban nem, hogy a unit teszt az nem ez. Vagy az a unit teszt, ami ilyen mentalitással készül készül, több problémát szül, mint amennyit megold.

Ha jól értem, abban nem értünk egyet, hogy valami tényleg favágás-e. A „code-first Entity Framework modellre kellett repository patternt csinálnom” igen, mert nincs benne semmi üzleti logika. Az „itt az alábbi metódus, írj rá unit-tesztet” viszont szerintem nem favágás.

De jobbat mondok, a csapat legseniorabb emberének a kódját sem szokás prodba tenni, ugyanazokon a folyamatokon kell átmennie (unit test, regression test, statikus analízis, teszt buildek, peer review, stb.), mint a nullkilométeres juniornak.

Ebben sincs köztünk ellentmondás. De azt mindannyian tudjuk, hogy a nagy, komplex, hosszú dolgok hajlamosan hamarabb átcsúszni ezen, mint a „hogyan is nevezzem ezt az propertyt” jellegű apróságok (lásd még bikeshedding). Innentől az, hogy valaki odacsesz ~10 unit tesztet (legyen 500 sor), hogy ezt generálta a chatgpt, akkor jóeséllyel tudjuk, hogy se ő nem nézte át rendesen, se a code review nem fog vele alaposan foglalkozni. És akkor néhány hónap múlva ott fogunk ülni, hogy az XYZ feltétel miért került vajon bele - senki nem tudja, átcsúszott a rengeteg változtatás közt, senki nem vette észre, ezt generálta a chatgpt...

Továbbra sem azt vitatom, hogy ez ne lenne hasznos eszköz. Sőt, azt se vitatom, amit te mondasz fent példát, hogy generáljunk le ismétődő, rövid, könnyen áttekinthető patterneket.

Azt mondom, hogy szerintem annak a generálására nem jó, aminek tömegesen kellene jelen lennie és ellenőrző szerepet kellene betöltenie egy kódbázisban. Ráadásul amikor a unit-test hibát jelez, akkor _nagyon pontosan_ kellene elmondania, hogy mi a hiba, és miért hiba.

Akkor már sokkal inkább használjuk fordítva: hogy hey chatgpt, itt van ~10 unit tesztem, ez lefedi a specifikáció minden részét szerintem, generáld már le azt a kódot, ami átmegy rajta.

a unit teszt az nem ez. Vagy az a unit teszt, ami ilyen mentalitással készül készül, több problémát szül, mint amennyit megold.

A unit test ideális esetben nem más, mint a low-level specifikáció angolról C#-ra fordított szövege. :)

Nekem azért favágás a teszt megírása, mert amikor ezt begépeltem, akkor a gépnek már minden szükséges információja megvan ahhoz, hogy befejezze a teszt megírását:

[Fact]
public void Returns_True_For_Odd_Numbers()
{

Innentől kezdve, ha tovább kell gépelni, az favágás.

Innentől az, hogy valaki odacsesz ~10 unit tesztet (legyen 500 sor), hogy ezt generálta a chatgpt, akkor jóeséllyel tudjuk, hogy se ő nem nézte át rendesen, se a code review nem fog vele alaposan foglalkozni.

Értem, de miért érdekes ez? Mi köze ennek a ChatGPT-hez?

Ha az LLM helyett a junior kolléga ír 500 sort, azt jobban átnézed? Ha valaki be akar küldeni egy 500 soros flaky tesztet, arra lelkiismeretfurdalás nélkül mehet a reject. Ha akkora a teszt scope, hogy már nem lehet review-zni (???), akkor azt kellene végiggondolni, hogy jól szervezett-e a kód, amit teszteltek. 

Nekem azért favágás a teszt megírása, mert amikor ezt begépeltem, akkor a gépnek már minden szükséges információja megvan ahhoz, hogy befejezze a teszt megírását:

[Fact]
public void Returns_True_For_Odd_Numbers()
{

Hány ilyet írsz munkaidőben? Szerintem ha szar, nempontos az implementáció, de a generált unit tesztben benne marad a hiba, akkor a unit teszt többet árt, mint használ.

Ez a capitalize metódus hasonlóan h'ót egyszerű a fentihez képest, aztán mégiscsak rágenerálja a ChatGPT néha, hogy

    @Test
    public void testCapitalize() {
        // Test case 1: Normal input
        String input1 = "hello";
        String expected1 = "Hello";
        String result1 = StringUtil.capitalize(input1);
        assertEquals(expected1, result1);

        // Test case 2: Empty string
        String input2 = "";
        assertThrows(IndexOutOfBoundsException.class, () -> StringUtil.capitalize(input2));

        // ...
    }

Aztán ha úgy kerülök oda javítani, hogy hm, kifejezetten erre az esetre van test case, akkor elgondolkozom azon, hogy én vagyok-e a hülye. Pedig nem, a fenti egy szar implementáció, javítva is lett, és a generált teszt is esélyesen szar lenne rá. Ahogy elismerem, arra is van esély, hogy a ChatGPT a jó tesztet generálja le, és ne a hibára/felesleges edge-case-re találjon rá - de ahogy bonyolódik az üzleti logika, úgy egyre nagyobb eséllyel lesznek gépiesen ráírt tesztek. És ezeknek nincs hozzáadott értéke. Szerintem sokkal több ilyen, a második keycloak kódhoz hasonló dolgot írsz te is munkaidőben, mint páros szám eldöntő dolgot...

Ha az LLM helyett a junior kolléga ír 500 sort, azt jobban átnézed?

Attól függ. Ha a junior kolléga a production kódja mellé írta, akkor igen. Ha csak gépiesen oda van adva neki, hogy „itt a prod kód Senior Sándortól, legyen rá a coverage 100%, mert akkor boldog a PM”, akkor nem. Lesz szíves Senior Sándor megírni a kis tesztjeit.

szerk.: Ha a junior kolléga a production kódja mellé írta, akkor igen. -> ha a junior kolléga unit tesztjei 500 sor, akkor lehet, hogy túl nagy feladatott kapott elsőre.

mégiscsak rágenerálja a ChatGPT néha, hogy

Nekem valami gyanús. Használtál már bármilyen LLM-alapú IDE plugint? Copilot, CodeWhisperer, stb.? y/n

Az a workflow, amit a kommented implikál, kb. nem létezik. Magától nem generál bele senki semmit a kódba, ezek úgy működnek, mint egy tetszőleges IDE kódkiegészítései, csak tovább lát a következő utasításnál. Nincs olyan, hogy a ChatGPT nyit egy PR-t, benne 500 sornyi teszttel.

Onnan indultunk, hogy a ChatGPT ír a kódodhoz unit teszteket (itt). Az egyetlen állításom, és az egész threadben nem akartam mást mondani, minthogy az workflow, hogy:

  1. írsz prod kódot
  2. odaadot a ChatGPT-nek, hogy írjon rá unit tesztet
  3. bemásolod a rengeteg soros eredményt a kódbázisba, és valamennyire átnézed (~all passed)

az egy rossz workflow.

bemásolod a rengeteg soros eredményt a kódbázisba, és valamennyire átnézed (~all passed)

Igen, és arról szólt a legelső kommentem a szálban, hogy ez mindenképpen rossz, akkor is, ha a chatgpt csinálja, meg akkor is, ha a kollégád. :)

Minden más már csak utólag lett hozzáköltve, hogy kinek a munkája a tesztírás, mi lesz a flaky tesztekkel, kell-e peer review, stb. Ez mind lényegtelen.

Pl.: ha jól emlékszem, a Javas HashMap-eknek elég sokáig prediktálható iterációs sorrendje volt, míg a javadoc-ja sehol nem állította ezt. Ha erre olyan teszt lett volna generálva, ami elvárja a sorrendet, akkor az a teszt onnantól nem segít, hanem hátráltat, hiszen fals-pozitív failing test van benne.

Szerintem semmi baj a fals pozitív tesztekkel, meg kell nézni, miért nem lesz zöld. Borítékolom, hogy az "elég sokáig prediktálható iterációs sorrend" egyben azt is jelenti, hogy bőven született olyan (nem teszt) kód, ami erre számított is.

Van egy YNAB klónom, ahol a saját kis büdzsémet vezetem, s akartam bele egy ilyen feature-t (tldr: „The algorithm generates 100 scenarios, each 10 years in length, by randomly selecting one-week periods from the user's transaction history, thereby creating 100 unique potential futures for the user based on their past behavior.”)

Egy helyen akartam belenyúlni: minél régebbi egy múltbéli adat, annál kisebb eséllyel kerüljön bele a mintavételbe (hiszen változnak a költési szokásaim, bevételeim, stb).

Két helyen használtam hozzá a ChatGPT-t:

  • mondjon tippeket a súlyfüggvényre, hogy mi alapján érdemes súlyozni a múltbéli adatokat
  • mondjon tippet arra, hogy milyen Java lib-bel lehet véletlen elemeket húzni, de úgy, hogy az egyes elemek súlya eltérő legyen

Az utóbbira hazudott be Guavas implementációt (ami nem létezik a gyakorlatban), de a végső megoldás is olyan libet (és súlyfüggvényt) használ, amit a ChatGPT mondott.

Nem értek egyet. Formailag az is fejlesztést segítő eszköz lehet, de akkor már minek álljunk meg itt, lehetne Google, meg Stackoverflow, esetleg még Github Co-pilot, meg a pizzafutár, aki a pizzát hozza, hogy kódolás közben éhen ne haljon valaki. A szavazás van rosszul címezve, valójában semmilyen segítő eszközről nincs szó, arra kíváncsi, hogy a kódot ki mivel gépeli be, melyik IDE vagy szövegszerkesztő.

Egyébként ha már szövegszerkesztő, ez a magyar fogalom is összemossa a text editort a word processorral (formázásra való az utóbbi). Nem is téved sokat, a neten én már láttam egy Computerphile videóban egy fejlesztő-auditáló faszit, aki Wordpad-ben nyitogatta a kódokat, a kommentelők is alig hittek a szemüknek, hogy szakemberben is van ilyen, aki rendesen ezért kapja a fizetését, nem hobbistáról van szó.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( Caro | 2023. 05. 28., v – 11:35 )

Hát az eclipse pontszámát látva, nem is csodálkozok hogy nálunk az van elterjedve :D

Teljesen megfelel nekem. Szeretem az olyan IDE-t ami egyben dashboard is.

Probáltam mást is. Igen.

 

Ha nem 49"-on tolnám, már váltottam volna, pl vscode-ra. persze ehhez az is kellene, hogy ne tudjam az editor ablakot fullra kapcsolni. :)

Ha nem 49"-on tolnám, már váltottam volna, pl vscode-ra.

Szerintem a vscode egy tök jó text editor, de nem helyettesítő terméke egy normális IDE-nek. 

Lehet, én vagyok elfogult pl. a jetbrains-es cuccokkal kapcsolatban, de én még a Visual Studio-t (nem a code, a nagy :)) is becseréltem Riderre, pedig ott meglehetősen szkeptikus voltam eleinte. Mégiscsak házon belüli termék a VS, de mint kiderült, ez nem sokat jelent. 

Emlékszem, mikor előző munkahelyemen .NET-ről vissza kellett váltanom PHP-ra, mert be kellett segíteni kollégának a weboldal fejlesztésében. VS után nagyon hánytam az Eclipsetől, akkor próbáltam ki a PHPStormot... Mekkora megváltás volt egy normálisan, stabilan működő debugger PHP-nál és egy nyelv lehetőségeihez mérten használható refactoring tool. Vagy a keresője. Utána vettünk licencet, PHP-s kolléga is átállt rá.

Jetbrains termékekhez hasonló triggerelés a kódkiegészítéshez beállítható Netbeans és Eclipse alatt is. Ha a kód jól strukturált, akkor nekem a refaktor sem okozott gondot.  Milyen gondjaid voltak vele?

Ps. kb Netbeans 12-nél ismerkedtem meg vele újra, és rákantattam. (Spring + PHP)

Nem csak kódkiegészítés, refactoring funkciók: tudjon projekt szinten átnevezni dolgokat, kódot kiemelni methodba, ilyesmik. Lehet, hogy ma már tud ilyesmit is, anno az Eclipse nem tudott. Debuggert még össze lehetett rakni, de.... nem volt valami tiszta, száraz életérzés.

Meg eleve, gyorsabb, reszponzívebb volt az egész JB, mint az Eclipse. NetBeans-szal nincs sok tapasztalatom, talán egyszer valami Java-s valamihez kipróbáltam, őszintén szólva nem emlékszem rá.

De igazából mindegy is, nagyjából 0 esélyt látok arra, hogy valaha is újra PHP-vel dolgozzak.

Eclipse-ben a trükk igazából nem csak az editor, hanem egy brutál mennyiségű olyan könyvtár és kiegészítő, amivel nagyon érdekes dolgokat lehet csinálni. Néhány példa:

https://www.eclipse.org/sirius/sirius-web.html

https://www.eclipse.org/viatra/

https://www.eclipse.org/epsilon/

https://www.eclipse.org/emfcloud/

https://www.eclipse.org/capella/

Részben igen. Az Eclipse Foundation egy csomó mindent hostol, viszont ezek a megoldások elég szépen össze vannak integrálva az Eclipse-el. Mondok egy példát. EMF egy metamodell nyelv, amiből bármit  is fel lehet építeni (pl. UML-t). Ha csinálsz egy saját modell-t ezen metamodell segítségével, akkor van hozzá olyan cucc, amivel pl. kapásból ki lehet generáltatni egy Eclipse Platform-ra épülő alkalmazást,  azaz lényegében egy DSL editor-t. De ne csak arra gondolj hogy egy sima DSL editort kapsz, hanem akár komplett grafikus modellező rendszert (mint pl. egy UML editor, csak saját nyelvre) is fel lehet így építeni, lehet hozzákapcsolni a fenti listából model transzformációkat, validátorokat, mindent, a fent említett Capella is például így működik.

Néhány érdekes videó, hogy milyen érdekes dolgokat tud az Eclipse:

Régebben itt tartottak:

https://www.youtube.com/watch?v=Xuartdq08ms

https://www.youtube.com/watch?v=fi4SVKlLs5E

Most meg itt:

https://www.youtube.com/watch?v=p_tDEzGtS0o

Én még mindig Eclipse-ezek. Bevallom, hogy Javára nem is nagyon próbáltam mást (csak Android IDE-t mini projektre), de nekem Javához rendkívül produktív. Még mindig elképesztően gyors benne egy fordítás-indítás-teszteredmény megjelenítés ciklus, és ameddig ez így van addig szeretni fogom. Szerintem az idők folyamán volt ami lassult benne, de aztán nagyrészt kikalapálták, meg a HW is hozzá nőtt. De durva skálázódási problémával nem találkoztam még.

Valójában C-re is alkalmas, egészen jól működik a CDT is. VisualStudio-zok is, meg még használok 1-2 IDE-t amit muszáj, és egyik sem ér fel az Eclipse-JDT (Java fejlesztő IDE) és Eclipse CDT (C fejlesztő IDE) szintjére. Leginkább a futtatás körök sebessége ami számít nekem, illetve a kódban ugrálás a hivatkozások mentén.

( apal v | 2023. 05. 28., v – 13:21 )

Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Az Atom is az, annak ellenére, hogy forkolták (Pulsar), azt se használja nagyon senki. Ezzel szemben egy Notepad++ felférhetett volna a listára, ha más nem, külön kategóriaként, pl. Scintilla-alapú eszközök (Notepad++, Code::Blocks, Geany, ConTEXT, notepadqq, SciTe, Commodo, stb..).

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A pycharm is oda sorolando, valoban. Szerintem felesleges kiemelni, ezt a felhasznaloik is tudjak maguktol - az aquaval ellentetben. (Mondjuk en az utobbit is tudtam, pedig azt nem hasznalom.)

A strange game. The only winning move is not to play. How about a nice game of chess?

( Raynes v | 2023. 05. 28., v – 19:41 )

Szerkesztve: 2023. 05. 28., v – 19:54

Nálam még mindig Vim, már kb. 5 éve, csak annyi változott, hogy a sima (nem göcsörtös) vim helyett neovim megy (ha olyan szerencsétlenség ér, hogy Windows előtt kell ülni, ott is), default config szinte, Lua-ban, nem sok plugin és cicoma van rajta. Mindenre, kicsi és nagy szerkesztésekre is. Nem csak programfejlsztés, de TeX, HTML, markdown, konfigfájlok, és nem kód jellegű szövegekre is, jegyzetelésre, tömeges fájlátnevezésre, parancssori szerkesztésre, visudo-nak, man pager-nek is ezt használom, illetve egy csomó más scriptem is használja, pl. jelszókezelő.

Ez a jó a vi-vim, és Emacs-vonalban, ezek sehova nem mennek. A többi rég megszűnik, átalakul, esetleg Windows, Linux is kihalhat egy ponton, de ezek mindig ott lesznek, elfutnak egy terminálban bármilyen POSIX-kompatiblis rendszeren. Egyszer megtanulja az ember, bekonfigurálja magának, nem kell állandóan újat megszokni, átképzőzni, stb..

Korábban én is megszívtam ezt, hogy mindig váltani kellett. Windows-on előbb ConTEXT-et, majd Notepad++-ot használtam, de ugye Linuxra váltással az ugrott (most már ott van helyette a notepadqq, ami nem egészen zárkózott fel hozzá, de közel van, ez még 9 éve nem játszott), aztán Linuxon Kate 4, de ezt meg elqrták, lebutították az 5-ös verziós újraírással, így mindenfélével kísérleteztem, Code::Blocks, TeXmaker, gedit, Commodo, UltraEdit, Geany, mcedit, végül hosszabb időre a SciTe jött. Közben mindig neki-nekifutottam a vim-nek, de állandóan lepattantam róla, évek kellettek, mire megértettem, hogy mi a lényege. Aki vim-et tanul, annak az a tanácsom, hogy ne konfigurálja agyon, ne könnyítsen (egérkezelés, nyílbillentűk, VSCode/Notepad++-szerű billentyűk beállítása), default használja, és próbálja úgy megszokni, vimtutor, vimgolf, stb. segíthet, YouTube-on is vannak jó tutorialok, előadások, stb..

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( kubi | 2023. 05. 28., v – 21:23 )

Valami ertelmes req management eszkoz + email, ppt es esetleg word. Aztan a szoftver kesz lesz.

( carlcolt | 2023. 05. 30., k – 11:45 )

Ez egy boomer hely hivatalosan is. A vim/emacs magas aranya is mutatja. :)

De C-re es C++-ra tenyleg nincs jobb es kesz.

(Bevallom, egy bizonyos level folott disturbs me too)

Pont ezért :D

Úgy látszik, nekem máshol van a péjn-tresholdom!

Amúgy meg azért zavar, mert a "boomer" egy USA-i kifejezés az USA-i népességrobbanásra a második VH. után (nem, nem amerikai, hiszen nem használják a kifejezést az egész kontinensen).

Magyarországon is volt ilyen, de annak más a neve.

A magyarnak mi a neve? Mert nekem ez a "retro-unoka" kicsit ambiguous (bocs) es nem igazan hallok ilyet kozbeszedben. Meggyozodesem, hogy ha valaki hasznalja is ezt a kifejezest, jo esellyel felreertik, hogy melyik korosztalyra gondolt.

Meg a haborus szaporulatos korosztaly kifejezes is jobban tetszene a retro-unokanal. Vagy lehetne uttorokent serdulo. Lehetne egyertelmubbeket kitalalni. De van olyan, amit kozbeszedben is hasznalnak?

Szerintem kezdjük el a fiatalokat "bloomernek" hívni, attól sokkal egyértelműbb lesz a dolog!!!444411

Csak egy tök másik nyelvet is meg kell tanulni (mit egyet? egy tucatot!) ahhoz, hogy értsed, hogy miről beszélnek körülötted az emberek "magyarul".

No problemo!441

Adtam rá egy plusz egyet, de a boomer kifejezésben benne van egy rakás olyan jelenség még, amit a Ratkó-gyerekek kifejezés nem takar. Időben valóban a Ratkó korszak gyermekei a megfelelői a boomereknek, de az életpályájuk annyira más a kettőnek, hogy nem lehet a boomeres mémeket egykönnyen magyarítani.

Nem, nagyon nem! A rock and roll életérzés nem a rock zene szeretetével egyenlő. A lényeg valami olyasmi, hogy az ősöktől kapott értékeket és életmódot eldobták. És helyette az élmények hajszolása lett az életcél. Ilyen jelmondatok, hogy "carpe diem", a "lényeg hogy jól érezd magad", "az élet célja a boldogság maximalizálása". Az Imagine című Beatles szám szövegét érdemes még tanulmányozni, abban sok minden benne van ebből. Eggyel korábbi generáció megbotránkozott volna rajta a boomerek pedig elsírják magukat, hogy de szép.

C/C++-ra bármi jó, azok annyira alap nyelvek, hogy bármilyen text editor meg IDE támogatja normálisan. Pont nem vízválasztó. A vim/emacs inkább abban erős, hogy jó minden másra is, és mindenre elérhető, nem mennek sehová évtizedek múlva sem. Bár azt is elismerem, hogy nem valók mindenkinek, aki nem szeret konfigurálgatni, meg reszelni, vagy újat tanulni, az valószínűbb valami készre gyúrtabb megoldást akar, mint a VSCode, Notepad++, stb..

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ez is egy érv, de akkor már vegyük ide az összes hasonló eszközt, cmake, m4, ninja, meson, stb.. Bár ezek inkább a buildelést segítik, nem a kódírást, amire a szavazás vonatkozik. Ha tényleg ennyire tágan értelmezzük, akkor bejönnek a debuggerek, meg automata tesztelési eszközök, és sose állunk meg. Már így is túl sok a szavazási lehetőség, szinte minden 2-3. komment az kb. az, hogy X vagy Y toolt is bele lehetett volna venni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( trey | 2023. 05. 30., k – 11:59 )

Az összes közül a ChatGPT 4% a legmeglepőbb.

trey @ gépház

Kesobb adtad hozza, masreszt most mi alapjan dontsem el, hogy a PyCharm vagy az-e a legjobb, ha teljesen masra valo?

Engem az lep meg inkabb, hogy a VSCode megveri az IntelliJ eszkozeit (mindkettot hasznalom, masra, sokkal tobbet tud az utobbi). Meg hogy a vi es tarsai ennyire jol allnak - bar ez lehet amiatt, hogy itt sok a rendszergazda, es nekik mar az is fejlesztes, amit abban muvelnek.

A strange game. The only winning move is not to play. How about a nice game of chess?

A JetBrains/IntelliJ visszafele fejlodik.

Elertek egyszer a peaket par eve, ez azota lefele vezet az ut.

Jon majd a kovetkezo. Szerintem van a fejlesztoknek igenye egy uj smart editorra. De senki nem kesziti el nekik.

Kezdetnek: miert van meg mindig mindegyikben defaultkent on top es nem oldalt a tab bar? (Nem erdekel, hogy nehanyban at lehet allitani, az alapbeallitasok miert kretenek?)

Folytatasnak meg Hiena blogposztja es alatta a kommentek: mindenki hulyen ir autocompletion algoritmust, es meg azt is megkavarja vele, aki az elozo verziot mar megszokta: https://hup.hu/node/181385

Juj. Ez a marketing anyag, amit keszitettek rola, borzaszto. Mar a preview is bloatware-nek nez ki, ajandek keyloggerrel.

Ranezesre hatarozottan nem az, amit egy fejleszto keres. Ez hamarabb lehetne az MS Word / Google Docs utodja.

Nagyon nem szeretem azt, amikor eloszor volt uzleti modell, masodjara strategia, es ezutani lepeskent ehhez igazitottak a UX-et.

A programozok nagy resze olyat keres, ahol a UX megtervezese volt az elso lepes, es a UX tervezesekor a marketing meg a beveteloptimalizalas a "majd lesz valahogy" kategoria. Sajnos ilyen uzleti analfabetizmus, ami vegul a felhasznalo javat szolgalta kiment a divatbol, 90-es es 2000-es evekben volt jellemzobb inkabb. :(

Nem feltétlenül értem, hogy mire gondolsz.

Amúgy úgy néz ki, hogy vim compatibility mode-ja is lesz, szóval engem már megvettek...

Szerk:

Na, úgy látszik, az XCode-nak már van vim-módja...

Tudtam én, hogy megéri megtanulni a Swift-et :)

https://til.hashrocket.com/posts/cmin5boyyz-enable-vim-mode-in-xcode-13

Szerk2:

Amúgy IDEA alatt is XCode színsémát használok kódszínezésre.

Valahogy jobban tetszik, mint a többi.

( Smokey2k | 2023. 06. 01., cs – 06:39 )

Kéne olyan opció hogy többet is ki lehessen választani.
Nekem sokat kell dolgoznom windows alatt is, ott ugye vsc-t használók, linuxok alatt neovim. És mostanában adtam egy lövést a chatgpt-nek meg copilotnak és meglepően megtetszett, hasznos kis cucc tud lenni.

( msandor v | 2023. 06. 13., k – 14:29 )

Mit javasoltok, ha elég a notepad++ tudása nekem, de natív Linuxos szoftvert keresek? (tudom, fut wine alatt, de ne már)

Én anno kipróbáltam egy rakás szerkesztőt, végül úgy voltam vele hogy kicsit beletanulok a vim-be......mielőtt valaki vim barbárnak néz... nem egyáltalán nem a legjobb ...stb.. viszont mivel linux alatt a legtöbbet használt cucc a terminál ezért az emacs vagy vi alapú cuccok a legideálisabbak.

Kate tudasa tul sok, vagy megfelel? Qt alapu, a KDE-s csomag resze. Sokaig hasznaltam fejleszteshez, ill. ha olyan a project es a nyelv, meg mindig hasznalom. Amugy akinek szempont, van Vi modja is (egyszer veletlenul aktivaltam, azota toroltem a hotkey-t).

A strange game. The only winning move is not to play. How about a nice game of chess?

Úgy rémlik, hogy korábban már kipróbáltam a Kate-et, de mivel nemrég váltottam Cinnamonra, nem sok KDE-s cucc van a gépemen. Megnéztem, 50 MB lenne, ha most feltelepíteném.

Viszont belebotlottam a neten ebbe: Notepad Next. Csak 32 MB az appimage fájl. Ha jól értem QT alapú. Nyomkodni fogom, aztán meglátom.