What are the Most Disliked Programming Languages?

Pontosan. Anno eljutottam oda, hogy a perltidy sem túrta át a kódomat :-P

Meg fogsz lepődni, de n+1 más nyelvben sem alap az enum... És ott is van rá csilliom jobb-rosszabb implementáció.

+1

Ezt a panaszt sosem értettem.

C-ben, C++-ban is úgy írtam programot (amikor még ilyesmivel foglalkoztam), hogy rendesen meg volt az behúzás.

Pythonban gyakorlatilag semmi mást nem kell csinálni, csak ugyanúgy írja az ember a dolgokat, mint amikor normálisan programozik, csak épp nem kell kitenni kapcsos zárójeleket, és mégis működik.

Nem arról van szó, hogy a python miatt valami olyasmit kell megtanulni, amit eddig még nem kellett. Nem arról van szó, hogy a python program valami logikátlan, semmihez nem hasonló módon használja a behúzást.

Tehát mint az utálatos Perl-ben, itt is lehet ugyanazt többféle, kezdő által értelmezhetőtől a tömör wtf() kódig terjedő módon leírni. Igaz, a space meg a tab használata kötelező és nem illik keverni, és ránézésre szép lesz a kód...

Az ES2017-ben érkezik a String.prototype.padStart(), amivel lehet.

Nekem se sok use case jut eszembe. De itt a lenyeg inkabb a nyelvi konzisztencian van. Minel tobb kivetelt kell fejben tartanod, annal nagyobb az esely, hogy valamit epp elfelejtessz.

Melyik az a nyelv, ami drasztikus változtatásokat csinált? A Java biztosan nem. A C# biztosan nem. A C++ sem, sőt, a C sem. Melyik nyelvekre gondolsz?

Mire kifejlodne a sok "live beta teszt" hibajabol, mindenki megtanulna, hogy hogy kell kikapcsolni

“A piac pedig gyorsan változik.”

Hoznál példát? Minden relatív, persze, de amikor valami fejlesztés irányt váltott piacváltozás miatt.

A fél év egy MVP leprogramozására értettem, prototipust mi három hét alatt is tudunk szállítani. egy hét alatt megmondjuk a főbb fejlesztési irányokat és két hét múlva már a legfontosabb komponensek tervei is kész vannak, tesztelve..

Ha ennyi idő alatt kijön egy konkurens, akkor így jártál, ha nem csináljuk, akkor is kijött volna. De ismét csak érdekelne konkrét példa, amikor egy cég abba bukott bele hogy a UX kutatás (mondjuk egy hét) tervezés és tesztelés (két hét) miatt picit később jutottak az amúgy jó market matchű termékkel piacra, és megbukott.

Mert olyanról hogy rögtön lekódolt félkész ötletekkel kering mint elsőgenerációs roomba porszívó a bútorraktárban, emiatt megelőzték, olyanról már hallotttam, de ilyenről még nem.

Az meg hogy valaki nincs benne eléggé a piacában hogy tudja, milyen szabályváltozások várhatóak fél éven belül (nem csak magyar esetben, de nemzetközi esetekben is), nos, az megint olyan hogy ott más baj is van szerintem a piacismerettel, piackapcsolattal, nem csak a határidő, de itt is kiváncsi lennék példára.

"Srácok, a pannon ma kijött a másodperc alapú számlázással"

Mondjuk erre speciel pont számítani kellett volna. Nem tudom volt-e nemzetközi előzménye, de még ha nem is volt, akkoriban baromi drága volt egy perc, és mindenki spúrkodott, hogy minél olcsóbb legyen a mobil.

Emlékszem, volt a három (1?) másodperces szabály: ha adott időn belül letetted, akkor nem számláztak. (Nem tudom igaz volt-e, de legenda volt.) Voltak ismerőseim, akik belehadarták a mondanivalót és letették. Ezért elterjedt, hogy csak akkor nyomják meg a zöld gombot, ha már a fülükön van a gép :-).

Én azt gondolom, az Agile Manifesto-t programozók irták, és az ő szempontjukból lett a helyzet kezelve, azaz:
- feltételezték, hogy piaci feedbacket csak futó kódra lehet kapni (valojában lehet prototipusra is)
- feltételezték, hogy a gyorsan változó követelmények a piac tulajdonsága (valójában az üzleti környezet többi összetevője - belső struktura, piacmegértés stb - sokkal gyorsabban változik)
- feltételezték, hogy ez megváltoztathatatlan sajátosság (az ő eszközeikkel tényleg, a mi eszközeinkkel nem)
- feltételezték, hogy a tervezés egy inherensen lassú folyamat (a régi eszközökkel tényleg, a mi eszközeinkkel nem)
- feltételezték, hogy a fejlesztés gyorsan, 2-3 hét alatt tud értéknövelt szolgáltatást teremteni (a jelenlegi ergonómiai és egyéb követelmények mellett ez ritka)

Jutottak valamilyen megoldásra, amely az ő nézőpontjukból, félre ne érts, megoldás, csak:
- nem képes ma azt a tempót tartani amit igért (te is 3 hónapot írsz élesbe állításra, nem 3 hetet)
- rendkivül drága (szorozd be a fizud munkáltatói költségét a csapatlétszámmal)
- olyan elemeket is változónak vesz amik más módszerekkel stabilizálhatóak
- amúgy hiába veszi változónak, a gyakorlatban éppúgy rosszul reagál rájuk (lassan, hekkeléssel, vagy felesleges komplexitással)

Ja, és kiesik az, hogy mennyire használható a piacnak a megoldás, amire ugye elsőnek gondolunk ha UX-ről van szó, nagyon darabosan és lassan (külön miniprojektekben) tud a használhatósági problémákra reagálni a klasszikus Agile.

Szóval nem gondolom, hogy az Agile lenne a Szent Grál, hiába hallgatom ezt évek óta.

Mi sem vagyunk a Szent Grál, mi azt gondoltuk végig, mi van a fejlesztés előtt:
- honnan tudjuk, a felhasználónak mi kell és miért az (user story)
- hogyan választjuk ki a lehetséges megvalósitások közül a legoptimálisabbat (patternek)
- hogyan kapunk a fejlesztésnél olcsóbban feedbacket a piacról
- hogyan tudunk a fejlesztésnél gyorsabban iterálni a terméken

Ez utóbbi kettővel amúgy az alkalmazkodási hajlandóság is nagyobb, ami a fejlesztések egyik nagy rákfenéje (embrace change, embrace change, de ha egy ház árát kiszámlázza a fejlesztőcég érte akkor annyira nem embrace)

Megoldunk ezzel néhány problémát, nem az összeset, de közelebb kerülünk egy valamelyes jobb megoldáshoz, mert azt gondolom, az Agile csomó dolgot nem oldott meg, főleg azokat nem, amik egy digitális termék fejlesztésénél a kódoláson kívül esnek...

“A legtöbb ügyfél maga sem tudja pontosan, hogy mit szeretne”

Persze, ezért vagyunk mi.

Ez nem arról szól hogy egy 100 wattos égőt az arcába tolok az ügyfélnek, hogy MONDD KI MIT AKARSZ ...

Kell neked egy új logisztikai rendszer... oké. Kimegyünk a logisztikai központodba, ott töltünk két napot az overálos emberek közt, mondjuk, hogy ezt meg ezt lehetne javitani. Közlöd, hogy neked az kéne, hogy 10%-kal kevesebb embert tudj alkalmazni mert baromi nehéz a HR recruitment mostanában.

Oké, megnézzük mik a kulcsfolyamatok amik emberszám alapúak, ezek szoftveres támogatását átszervezzük, építünk rá egy protót, egyik nap munka után eljátsszuk a munkatársak egy részével. Kiderül hogy valamire nem gondoltunk, átvariáljuk, másnapra van egy szoftver amire a köv műszak azt mondja, tök triviális és működik.

Bevisszük a jogászodhoz, elmondja, hogy van egy törvény ami miatt ezt így nem, és hogy amúgy minisztériumi pletyka hogy januártól így lesz, meg van egy olyan felsővezetői mozgolódás hogy amügy legyen.

Mindegyik esetre készítünk altrernatíváiat, kivisszük tesztelni, akár 2-3 forgatókönyvet is. A végére minden ismert esetre fel vagyunk készülve, a mérések azt mutatják, hogy felgyorsul annyira a használat hogy nem kell annyi ember hozzá.

Leírjuk azokat a részeket amik az eredeti célszámok teljesítéséhez feltétlenül kellenek, a protót szétszedjük komponensekre, react/atomic design / amit a céged használ épp elemekre, pszeudokóddal, cross-referenciázva a követelményekre. Ellenőrízzük, hogy a változó életciklusok stimmelnek-e, minden adat konzisztens, minden adat beszerezhető, részben a fejlesztőkkel együtt. Rábólintatunk az összes kisfőnökkel, nagyfőnökkel, overálosokkal és jogászokkal.

Akkor se lennél kész sokkal előbb ha mi ezt a kört nem futjuk le, de akkor mindenki ideges lenne. Így mind a menedzsment, mind az overalosok tudják, mire számíthatnak, a pm-ek tudnak priorizálni, a tesztelők előre meg tudják írni a tesztforgatókönyvet, a programozók pedig tudnak miből dolgozni.

Ezt az egész A,B,C... funkciós A’-s stb köröket, ezeket mi futjuk le a prototípusokkal, a fejlesztő már csak azt kapja meg hogy ilyet szeretnénk, kerek legyen és babakék, négy kerékkel és neonvilágítással.

Tudom hogy scifinek tűnik de tényleg hatalmas csend van utána a menedzsment részéről, kéthetente ledemózol (azt mi visszük tesztelni), oszt kész, nincs cserélgetés, kitalálás.