trollantyu

valasz erre: http://hup.hu/cikkek/20101101/hovd_2010_kedvenc_programfejlesztest_segito_eszkoz#comment-1150431
igen, szivesebben dolgoznek olyan szamologeppel (mert a gep az nem szamit semmire) aminek meg volt mernoki pultja ;)
vagy pontosan tudtad, hogy mi zajlik a gepben, vagy a szereloket hivtad, mert hw-hiba tortent. ma maximum sejted.
ez nem azt jelenti, hogy lyukszalagokat akarok cserelgetni, a fejlodes valtozassal jar, ezzel nincs is baj. van, ami egesz kenyelmes (szeretem a javat minden hulyesege ellenere, bizonyos problemakat nagyon elegansan lehet vele megoldani) csak ne kezdjunk bizonyos divatos programozasi paradigmakra az egy igaz megvaltokent tekinteni.

es te ne haragudj, de akkor fuss haza az architecture-astronaut haverokhoz, es verjetek egyutt a tobbszorosen orokolt szuperszexi interfaceitekre, az informaciora mindorokke az adat felett, le a cleartext tunellekkel, objektumokat mindenhova, es porgesd tovabb a design patterns konyved :)

Hozzászólások

+1
jó dolog az absztrakció, de nem kéne túlzásba vinni
(btw szerintem a vim nagyon jó, és sokszor jóval hatékonyabb mint a legtöbb 'modern' IDE)

Egy szukseges rossz a tulbonyolitott architektura, amikor 100 fejleszto ugyanazon a termeken dolgozik, segit iranyban tartani a fejlesztest. Habar en ruhellem a 10+ retegu kodokat.

---
return NEVER;

Ubuntu 8.10
HP nx6110
http://java.tszebeni.hu

en mar azert sem ertem az ilyen agressziv tamadast, mert a szoftverfejlesztes (mondjuk az elso tervezesi fazis utan) nagyreszt a forraskod irasaval illetve az abban torteno navigalassal telik, emiatt egy jo szovegszerkeszto hatamas segitseg...

mondjuk neha az en fejemben is megfordul, hogy milyen jo volt akkor, amikor a szamitogep-kezelo/programozo meg valami misztikus, hatalmas tudasu eloleny volt, aki csodat tett a szekrenymeretu gepek kozott (bar sokan ma is igy latjak azt aki tuljutott a Start gomb megnyomasan :D)
-
Slackware current / OSX Snow Leopard

programfejlesztéstről és nem kódolásról volt szó

igen, valóban lehet úgy dolgozni hogy gőzöd sincs miről van szó, én is elkövettem olyat töbször is hogy egy lefordított exe-ben egyszerűen kicseréltem egyik bájtsorozatot másikra, anélkül hogy értettem volna hogy működik nemhogy a program, még az exe szerkezetét sem ismertem, csak tudtam hogy valahova 1234-et írt és azt írtam áz 9999-re.. működött

de ha nekem egy kóder úgy ír át valamit hogy ":1,% s/a + b/a + c/g" akkor az inkább ne is kódoljon, (erőltett példa értsd mit mondok), vagy a következő előfordulásra ugrik? igen a csillag mechanikusan a következő blokkban is ahol már teljesen más változó az a sztring, arra is ráugrik

neked hobbid hogy mindenfele oda nem illo baromsagot irsz valasz helyett? baromira nem tartozik ide, hogy te mit csinalsz a hexeditoroddal
meg mi az hogy 'gozod sincs mirol van szo'? aki forraskodot ir, annak mar koze sincs? tehat ha jol ertem, szerinted a click-click RAD eszkoz az egyetlen, ami fejlesztes, minden mas csak folosleges baromsag?

az a regexp meg megint hogy jon ide (amellett hogy meg csak nem is jo)?
-
Slackware current / OSX Snow Leopard

mi az hogy nem jó? vim-ben cseráli az "a + b" karaktersorozatot "a + c"-ra? és mi az hogy nem jó, odaírtam hogy értsd jól, de ha tényleg ebbe kötsz bele semmi rtelme erről vitatkozni, olyanról akarsz meggyőzni hogy jó amit kettőnk közül én ismerek?

mi az hogy oda nem illő? kódot írni bármiben lehet amiben otthon vagy, réggebbi kódodat újraolvasni, más kódját olvasni már nem olyan egyszerű, ha amiben írsz csak mechanikusan kiszínezi, előbb utóbb bajba jutsz

a clickclick(nemtommiazaz)RAD meg igenis eveszi a terhet a válladról hogy óvatosan meg kelljen nézned hogy épp a kódfaragásoddal nem-e rontasz el valamit, mert nem mechanikusan szúrsz be valamit egy "regexppel", hanem a program szerkezetéet ismerő eszközzel

nem kell a világot atomi szinten kezelnned ha már vmár építettél rá egy magasabb szintű eszközt akkor azt használjuk

jó ezt elbgépgeltem, de a lényegen nem változtat hogy nem abba amit mondani akartam kötött bele és még csak nem is abba hogy leegyszerűsítettem, hanem hogy elírtam, egy ilyen vitának semmi értelme

midegy, nekem a téma a "segítő eszköz" volt ami segít, tehát van amit helyettem tesz, nem pedig egy "eszköz", ami pontosan azt teszi amit mondik neki és a tudás/felelősség teljes egészében nálam van

igen, a vim és a jelen értelemben hasonló eszközök jók, amíg az ember tényleg bitszinten képes uralni a teljes kódot, nálam ez kb aúgy látszik az első karakterekig terjed.. :)

az, hogy egy binaris file-ban hexeditorral mit buveszkedsz, szerintem a legkevesbe sem 'oda illo' amikor szoftverfejlesztesrol van szo

a regexp nem vim-specifikus, a legtobb IDE-ben/szerkesztoben van, szoval nem ertem hogy ez pl. hogy jott ide (vagy az a bajod, hogy miert :% es nem CTRL-F, TAB, stb?)

a RAD sok helyzetben segit, de van amikor semmire nem mesz vele. a szoftverfejlesztes nem (csak) olyan feladatokbol all, amiket egyetemen mutogatnak, hogy csinalj egy telefonkonyv alkalmazast SQL-kapcsolattal. azt valoban ossze lehet kattintgatni, de mit csinalsz ha mondjuk kezi jatekkonzolon, PC-n (Windows/Linux/OSX), meg ki tudja milyen platformon futo jatekot akarsz fejleszteni? bizonyos dolgokhoz ott is vannak ugyes engine-ek, frameworkok, de kozel sem biztos, raadasul a kod irasat ott sem tudod megkerulni, hiaba olyan jo mondjuk a Unity.

nincs az osszes lehetseges feladatot magikusan megoldo eszkoz. ha olyan a feladat, amire nincs celeszkoz, vagy valamiert nem felel meg, akkor igenis neki kell allni, es megcsinalni, aminek igen nagy resze a kod megirasa, amiben (vissza az alapfelveteshez) egy jo minosegu, nagy tudasu szerkeszto hatalmas segitseg

"réggebbi kódodat újraolvasni, más kódját olvasni már nem olyan egyszerű, ha amiben írsz csak mechanikusan kiszínezi, előbb utóbb bajba jutsz"
na ezt megint nem tudom igazan ertelmezni... mire akartal ezzel utalni? a jelenlegi project, amiben dolgozom kb. egymillio kodsor, es nem, nem lehetett csilivili eszkozokkel osszekattogtatni, annal sokkal specialisabb a feladat
-
Slackware current / OSX Snow Leopard

lentebb panthernek is meg általban

elfelejtitek a kontextust ahol kezdődött, azaz az absztrakciót

NEM a kttintgatásról volt szó hogy könnyebb mit a regexp, anem hogy a "regexp" elemei nem karakterek hanem plusz jelentéssel bíró dolgok

a programfejlesztésben kell egy jó szövegszerkesztő amivel olyan dolgokat is lehet csinálni ami nyelve még nincs a rendszerben, és kell is, ide jó a vim

arra reagáltam hogy valaki az egész projectet úgy aogy van a fejében tarja és eszköznek csak ilyen gyenge regexpetket használ amibe a pluginek függvénykeresését értem nem az egyszerű stringcseréket tehát NEM a ":% s.." kontra ctrl+f -ről beszélek, hanem kicsit elvontabban

a lényeg hogy a vim-ben sehol nincs benne a nyelv, (pl c), csak (kiscsit eröltetve) regexpekkel rákeres olyan sztringre ami "valami()" alakú

igen, van a vimnek jogosultsága sőt van ahol csak az jön szóba, mégegyszer: arra reagáltam hogy valaki kategórikusan kijelenti hogy absztrakció nem kell

szerintem senki nem jelentette ki kategorikusan hogy 'absztrakcio nem kell'
nyilvan kell, sot, gyakorlatilag maga a fejlesztes is nyilvan egy absztrakcios folyamat

en azt a kirohanasodat nem ertettem, hogy miert ne lenne egy (forraskod irasat rengeteg funkcioval segito) szovegszerkeszto fejlesztesi segedeszkoz.

az altalad felsorolt hibak (az egesz project a fejben, stb) meg nem eszkozfuggoek, ha ilyen elofordul akkor ott sem a projectmanager sem a fejleszto nem vegzi jol a dolgat
-
Slackware current / OSX Snow Leopard

ahogy a másik topikban is írtam, és itt is az összes szempont együttvéve, azaz valahol természetesen segédeszköz, de nem fér a konkrét tizes listába (ettől még ha trey mégis beteszi akkor már én is a vimre szavazok)

egész egyserűen elüt a többitől aban hogy hogyan segít, más téma szerintem mint a többi, külön lehetne vim, emacs, konkrét bas szkript, ... lehetőségekkel, önmagában nincs értelme mert a szövegszszerkesztő része a többinek, eclips projektben is van amit inkább vimmel csinálok, vagy eyéb konkrét szkripttel

és ehez MELLÉKSZÁLKÉNT felhoztam (tehát lényegében a témához semmi köze) hogy mi az ami leginkább nem tetszik a vimben, azaz hogy túl alacsoníszintű

igazabol a kategoriak nevei tul tagak, ezert is megy mindig a civakodas hogy 'melyik 10'
en a magam reszerol ugy ertelmezem, hogy nekem a legjobb fejlesztest segito eszkoz az, amit a leginkabb hianyolnek ha leultetnenek egy gep ele azzal hogy 'mukodj, fejlessz'
ha g++ helyett VS fordit, azt kibirom, legfeljebb morgok, ha nem kapok csilivili IDE-t, akkor is, UML-es segedeszkoz nelkul is elboldogulok, de jofajta szovegszerkeszto nelkul hisztizek es kurvaanyazok :D

-
Slackware current / OSX Snow Leopard

A másik témában konkrétan "Kedvenc programfejlesztést segítő eszköz"-ről volt szó. Nekem az eclipse csak egyes, vim/emacs esetén nehezebben megvalósítható funkcókban nyújt segítséget... Tehát nálam pl. a vim/emacs és a "többi" pont fordított relációban van.

Szóval: itt nem az a kérdés, hogy a világ 99,99999999999999999%-a mit használ, hanem a hup olvasói között mi a helyzet.

nyilván ha trey összeszámolja a szavazatokat és úgy dönt akkor beteszi, én a véleményem mondtam el amit relevánsnak tartok itt (és nem a világban):
hogy ennyi erővel vim helyett c-t is lehetne írni.. nyilván jó ha annyi munkát belefektetsz hogy lényegében megírod a _saját_ fejlesztői környezeted, emiatt tartom értelmetlennek mint kategóriát, hanecsak nem "vim/emacs/c/egyéb saját környezet" :)

No, ha már fejlesztés: melyik IDE (bármi más) tudja helyettesíteni pl. a sokéves fejlesztés során összepakolt, egy-egy konkrét részfeladatra megírt shell szkriptjeimet? A hatékonyság fontos, ezért amit többször is használok, arra valami ilyesmit írok, néha éppen C-ben, ha olyan kedvem van. De mindez gyorsabb, mint kitalálni, hogy az aktuális IDE verzióbabe hogyan lehet extensionként megírni... Főleg, hogy ezek működnek bármely gépen, elég felmásolni (scp), és akár egy 128 MiB memóriával ellátott gépen is gond nélkül mennek. Vagy még inkább ott, ahol nincs is X és nem is lesz soha.

semmi rendszerszemlélet

a világon mindenki azon dolgozik hogy az általa használt világrészletre egy modellt ültessen, mert az jó, ha a kiskocsit akarom megmondani hogy kell meglökni hogy a lejtő közepén álljon meg ilyen elvont köztes absztrakcióüs réteget szenvedünk be, nem pedig a a rendszer ismeret nélkül keresünk valamit amit változtatni tudunk aztán hexában átírjuk és nézzük hogy már jó-e aztán rájövünk hogy a kerékszín átírása nem segít, aztán a következő módosításnál már a fizika törvényét, agrav.együtthatót írtuk át és épp az lett amit akartunk, működik, leadjuk

igen, lehet a rendszer ismerete nélkül dolgozni, rengetegszer találkozok olyannal hogy kérdez valaki ésa magyarázat nem jó, mert nem akarja érteni, az fárasztó, bőven elég neki hogy akkor most lehet-etöbb gépre ugyanazt a portot forvardolni vagy nem.. tehát a kimerítő válasz az igen vagy nem, nem valami logika amivel esetleg máshol is tudna dolgozni

mint ahogy a programban is lehetazt az absztrakciós réteget újra használni máshol és nem kell újra átírni hogy most már ne csak az a+b hanem b+a-ra is keressen rá

igen, "boldogok a lelki szegények...", az operátor is milyen jó is volt hogy villant a lámpa, na akkor cseréljünk szallagot... nem kell neki tudnia hogy mi van azon a szallagon vagy miért kell cseréélni, teszi az egybites szabályrendszerrel leírható munkáját oszt elvan

további kellemes kódfaragást

a kozuk van egymashoz!=ugyan az, te pedig erre epitettel
a rendszerekkel szembeni legfontosabb kovetelmeny meg az egyszeruseg
ne probaljuk meg meg nehany reteg szines-mazos szarral elfedni a problemat.
(hogy meddig mukodik jol a redukcionista szemlelet, az mar gyakorlati problema)
a fizikusok is tuti viccbol keresik az egyesitett elmeletet, nem is ertem miert
nem jok nekik a meglevoek, hiszen a sajat nagysagrendukon tokeletesen jo mukodnek.
de kar beled az eletron..