Üdv! Én találtam egy kissebb esztétikai hibát a cikkeknél a "Tovább" el van csúszva. [link]Egyébként nagyon jó az oldal, tetszenek a cikkek, csak így tovább!

[ Szerkesztve ]

"Az idővel egy úton rohan az élet, De az utat a célig mi építjük meg."

múltkor pont ilyen kettétört billentyűzetek után kerestem

win7 élményindex 7.3 :)

Hello!

Nekem tetszik az oldalatok, jó a szín összeállítás is. Egy kicsit hiányolom a cikkekből a képeket. Vagy ha van és csak én voltam figyelmetlen, akkor kövezzetek meg
Sok sikert!

Ihn nikho! Mahna nikho mha nahna e rei!__....Ͼʘ.ʘϿ....__Mha nahno mha nah rikho! Ihni Kohei!

A fejlécben az oldal címe nagyon zavaros, kellemetlen feladat elolvasni. A sötét háttéren a fehér betűk túl sok helyen vannak kiemelve és így nem terelődik a figyelem a lényegre, illetve az egész oldal hangsúlyos tőle.
Elsőre azt gondolná az ember ha csak két színből építkezik akkor abból nagy baj nem lehet. Pedig de. Használj árnyalatokat a kiemeléshez.

Alapjában véve a lényeg az legyen (már ami a designt illeti), hogy kellemes legyen ránézni. Jól olvasható strukturált szerkezetet valósítsatok meg. Ez jelenleg egy nagy és nehezen olvasható massza (nem sértésként, építő szándékkal írom).

[ Szerkesztve ]

Hehh...na most találtam meg a Galériát Még reggel van.

[ Szerkesztve ]

Ihn nikho! Mahna nikho mha nahna e rei!__....Ͼʘ.ʘϿ....__Mha nahno mha nah rikho! Ihni Kohei!

Grat a honlaphoz, jó lett.

Ezt csak hobbiból csináltad kályhától indulva, vagy ennyire nem feleltek meg a meglévő CMS-ek? Persze előbbit megértem, én is utálom más munkáját használni... (És... PHP... Én lennék a világ ura, betiltanám. )

Gratulálok a honlaphoz! Biztosan rengeteg munka van benne. A kinézet majd alakulni fog, elsőre szerintem nem rossz, de a betűk színe kicsit zavaró, a főoldal kicsit összevissza, de szerintem 1.0-ás verzióhoz képest határozottan jó. Csak így tovább!

Ja és, Win7 RC tesztet a népnek

Nekem tetszik az oldal, gratulálok!

Az akasztott embert még az ág is húzza

Elég merész hirdetni a konkureciát a logouton.

***

ha be vannak állítva a fontok a böngészőben, akkor elég ronda lesz az oldal...

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

nem hiszem, hogy ez (még) nem konkurencia a logoutnak, ahhoz még el kell telnie egy kis időnek

Amúgy szép oldal, csak kicsit átláthatatlan

hja, ha az embernek nincs szocialis kapcsolata, mindenkihez probal beszelni, ebbol lesznek az utcan motyogo oregasszonyok - meg a bloggerek ٩(̾●̮̮̃̾•̃̾)۶

Na, most értem haza, bocs, hogy eddig nem tudtam válaszolgatni, de akkor lássuk sorban.
For357y: Látom te Ubuntu alól nézed, valószínűleg ott lehet a baj, talán nincs meg ez a betűkészlet, máshogy jönnek ki a pixelek, azért csúszik el. Win alól jó, de azért majd próbálok tenni valamit az ügyben.
Egorov: Örülök, hogy tetszik! Képek: egyrészt, mint írtad később, van galéria, másrészt meg - bár tudom, ez nem mentség - a cikkek java része még nem ide íródott, ezért nincsenek benne képek. De az utolsó egy-kettőbe már például van, és a későbbiekben is mindenképpen lesznek.
Dottore: Ez a túl hangsúlyos dolog érdekes, erre nem gondoltunk, de tényleg. Nem vezeti az ember szemét. Ezen el fogunk gondolkodni.
ddekany: Igazándiból egyrészt szeretem, szeretjük ezt csinálni, másrészt meg mindenképpen szerettem volna egy nagy, saját kódbázist, amit esetleges későbbi fizetős melóknál föl tudok majd használni. Meg persze én is utálom másét használni.
^Clown: Lásd a Dottore-s választ, köszönöm az észrevételt!
ollie: Talán nem annyira hirdetés, végül is a végére merészeltem csak betenni egy szem linket, ami nélkül kicsit csonka lett volna, másrészt meg nem konkurencia. Félek ugyanis, kicsit messze vagyunk még attól, hogy a Logout-al konkuráljunk... Sőt, nem is az a cél, hiszen alapvetően mi nem akarjuk megengedni bárkinek a blogolást, csak pár "kiválasztott" embernek. Ráadásul az írás szerintem témába vág, érdekes lehet a Logout olvasóinak.
bambano: Ja, ez ellen tennünk kell majd valamit. Ötlete valakinek?

A kód nagyjából rendben van, de mivel már a csapból is az ilyen informatikai/hobbi portálok folynak, nem hinném, hogy életképes lenne a dolog, de ne legyen igazam.

Ja, hát ez olyan, hogy hiába lehetne sütireceptekkel bankot robbantani, ha egyszer nem érdekel. (A sütireceptpiac online lefedettségét nem ismerem, csak hasból mondtam.)

szép munka. mind designilag, mind motorilag. tudom mennyi munka egyedül megírni egy egész portálrendszert mert többször is csináltam. most úgy vagyok már vele hogy 112(7x16) óra alatt meg tudok csinálni egy honlapot desingnnal is.

mármint egy teljesen sajátkezülegírt honlapot

A honlap elég jó lenne, de a kinézete az tragikus, ezer sebből vérzik.
- A fekete alapon fehér szöveg nagyon jól mutat egy divatház látványos flash-es honlapjain, ahol egy átlagos oldalon 5-6 sor szöveg van. Nagy mennyiségű folyó szövegnél a fekete háttér/fehér betű kombináció olvashatatlan.
- Betűtípusok, link stílusok nagyon nincsenek rendben, minden teljesen esetleges.
- A cikkek címe, szövege, a navigáció és a cikkhez tartozó további információk, a menük és a fejléc grafikája egyáltalán nem különülnek el egymástól látvány szempontjából, ezért teljesen átláthatatlan az oldal.
- stb.stb.

Javaslom, hogy keressetek meg egy profi webgrafikust, aki konkrét segítséget tud nyújtani ebben. Ezt leszámítva az oldallal semmi probléma, tetszetős és viszonylag strukturált, szóval jó munkát

"másrészt meg mindenképpen szerettem volna egy nagy, saját kódbázist, amit esetleges későbbi fizetős melóknál föl tudok majd használni"

Sok, ha nem a legtöbb Open Source cucc licence ezt zökkenőmentesen lehetővé teszi.

De olvasd el megint, amit idéztél... SAJÁT kódbázist. Tudom én, hogy jogilag lehet úgymond az enyém is, de én tényleg sajátot akartam, amiben szívem lelkem benne van, és főleg átlátom, pontosan értem a működését. Egy open source kódot is átfuthatok, megértve a működését, de azt elfelejtem, ez meg meg örök. Tudom kicsit beteges, de én szeretem magam megoldani a problémákat, maximum a php manualt hívom segítségül egy-egy függvény pontos szintaktikájáért.

Mindenkinek köszönöm a visszajelzéseket, ezeket figyelembe vége hamarosan indul az 1.1-es verzió fejlesztése.

Megértem én maximálisan, én is ilyen vagyok... csak a kereskedelmi megfontolások kapcsán reagáltam, mert hogy ott nincs gond.

(PHP helyett Java-t megfontoltátok amúgy? Sajnos nem tudom palástolni mélységes PHP gyűlöletemet... Ha valaki "script nyelv" hívő is, akkor legalább Ruby vagy hasonló... PHP mind mint nyelv, mind mint webes "framework" gány. Csak jókor volt jó helyen, aztán máig talán a legelterjedtebb ha Web oldalakról van szó. OK, pont emiatt jó sok web orientált könyvtár meg egyéb tool van hozzá, de hát kreatív fúr-farag emberként miért választja vki... talán csak megszokás?)

PHP helyett Java-t megfontoltátok amúgy? Sajnos nem tudom palástolni mélységes PHP gyűlöletemet... Ha valaki "script nyelv" hívő is, akkor legalább Ruby vagy hasonló... PHP mind mint nyelv, mind mint webes "framework" gány.
Mondjuk mert sokkal gyorsabb megírni apróbb dolgokat php-ban, mint java-ban? (ez a scriptnyelvség előnye). Meg mondjuk két sörért lehet kapni php-s webhosting-ot, Ruby-val vagy Java-val kicsit körülményesebb. Amúgy lehet php-ban normális minőségű kódot is készíteni, nem csak összegányolt hulladékot, szóval ezen nem múlik semmi szerintem..

[ Szerkesztve ]

Igazándiból ez a legelterjedtebb, ezt használják legtöbben, emellett gyors és támogatott, ezek voltak az indokok. Meg könnyű volt megtanulni. Most meg már ha nekiállok valaminek, az a C++ lesz.
(Kereskedelmi megfontolások, ok, értem már, akkor nem szóltam.)

"Mondjuk mert sokkal gyorsabb megírni apróbb dolgokat php-ban, mint java-ban?"

Mondjuk ahogy az IDE-k fejlődnek, ez egyre kevésbé igaz (mert hogy sokkal segítőkészebb IDE támogatást lehet írni "statikusabb" nyelvekhez, stb), de egye fene... Viszont ez egy lényegében egy CMS + miegymás, amit ráadásul hosszú távon tovább fog nőni, ha jól értettem. Azért úgy már minimum, hogy rezeg a léc...

"Meg mondjuk két sörért lehet kapni php-s webhosting-ot, Ruby-val vagy Java-val kicsit körülményesebb."

Sajnos, ez tény... bár azért a Java-s hosting-ot nem annyira vészes.

"Amúgy lehet php-ban normális minőségű kódot is készíteni, nem csak összegányolt hulladékot, szóval ezen nem múlik semmi szerintem.."

Hááát... szóval mikor a standard funkciók a hibát visszatérés értékkel jelzik, akkor részemről kapásból a viszont látásra. Tudom PHP 5 óta vannak exception-ok, azaz... 2004 óta. Húúúú! Csak hát ott van még rakás régi könyvtár. De hát még sorolhatnánk... Nem is hibáztatom a PHP készítőit, mert hát ismert hogy jött létre ez a nyelv. A gáz az, hogy ha már soha nem tud ezen túllépni a világ. Aztán meg, úgy általában fel kéne már fogni a világnak, hogy orba-szájba dinamikus nyelvből (pl. PHP) nem viccess nagyobb API-kat meg úgy általában nagyobb kódbázist építeni. Persze lehet... csak nem kéne. Ne nevezzük gánynak, csak mondjuk rémálomnak.

[ Szerkesztve ]

Viszont ez egy lényegében egy CMS + miegymás, amit ráadásul hosszú távon tovább fog nőni, ha jól értettem. Azért úgy már minimum, hogy rezeg a léc...
Dolgoztam már nagy php-s framework-ön, egyáltalán nem rezgett a léc. Php-ben is lehet normális minőségű kódot írni, csak akarni kell, meg persze valamennyire érteni hozzá.
A php rossz hírét főleg annak köszönheti, hogy nagyon könnyen hozzáférhető és rövid idő alatt össze lehet benne rakni egyszerű oldalakat - ez pedig vonzza a hozzá nem értő júzereket is, mert rendes programozási tudás nélkül is lehet vele boldogulni.

Hááát... szóval mikor a standard funkciók a hibát visszatérés értékkel jelzik, akkor részemről kapásból a viszont látásra. Tudom PHP 5 óta vannak exception-ok, azaz... 2004 óta. Húúúú!
Pedig sokszor nagyon hatékony ez az elgondolás. Amúgy a scirptnyelv jelleg miatt van ez így.

Aztán meg, úgy általában fel kéne már fogni a világnak, hogy orba-szájba dinamikus nyelvből (pl. PHP) nem viccess nagyobb API-kat meg úgy általában nagyobb kódbázist építeni.
Ez csak szándék kérdése. Az orrba-szájba dinamikusság miatt a legnagyobb probléma az, hogy fejlesztés során nem működik rendesen az automata kódkiegészítés, ezt leszámítva normálisan felépített rendszerben ez nem jelent gondot. (Plusz ne feledjük, az orrbaszájba dinamikusságnak vannak előnyös oldalai is). Ahogy már írtam, volt szerencsém nagyméretű, igen magas absztrakciós szintet megvalósító php-s framework-höz, egyáltalán nem nevezném rémálomnak.

[ Szerkesztve ]

"Pedig sokszor nagyon hatékony ez az elgondolás." [az exception-ok hiánya]

Mikor?

"Ez csak szándék kérdése. Az orrba-szájba dinamikusság miatt a legnagyobb probléma az, hogy fejlesztés során nem működik rendesen az automata kódkiegészítés,"

Ami önmagában is könnyen azt jelentheti, hogy amit nyertünk a réven, azt elvesztettük a vámon, pláne ha olyan API-ról van szó amit sokan és sok helyen fognak használni. De a gond az, hogy ennek oka is van, hogy az auto-kiegészítés nem megy... és ugyan amiatt nem fog menni a refactoring sem rendesen, stb.

"Ahogy már írtam, volt szerencsém nagyméretű, igen magas absztrakciós szintet megvalósító php-s framework-höz, egyáltalán nem nevezném rémálomnak."

Kellő tehetséggel és energia ráfordítással mindent meg lehet írni bármiben... csak miért kell a nehezebb utat választani. Persze azt hiszem tudjuk miért... van egy programozó szubkultúra aki ezt szokta meg, aztán annyi. De most tényleg, miféle gondolkodás mód igazolja mondjuk -- hogy egy szándékosan egyszerű dolgot mondjak --, hogy nem hogy nem kell, de nem is lehet a funkció argumentumok típusát deklarálni? Miért? Ez az apróság teljesen jól tükrözi a PHP és társai szemléletét... nem gondolkodnak karbantarthatóságban, és abban, hogy a programnyelv fejlesztés közben minél több "benézést" elkapjon. Persze a "rideg" nyelveket használók tábora is egy érdekes állatfajta... ők meg feleslegesen fapadosan hagyják a nyelveket általában, hogy jó kényelmetlen legyen... ugyan ez a nyakkendős enterprise-os impotens nehézkesség persze áthatja az nyelvhez készült könyvtárakat is... pedig technikailag ezt nem indokolja semmi.

"Pedig sokszor nagyon hatékony ez az elgondolás." [az exception-ok hiánya]
Mikor?
Most nincs időm konkrét példát írni, de a lényeg, hogy a típustalanság és a php függvények logikája miatt nagyon körülményes lenne a programozás, ha minden függvény exception-öket dobálna, ha valami fáj neki. Az exception elvileg arra jó, hogy ha valami probléma van a program működésével, akkor jelezze. A php nyelv lazasága miatt sokszor az egyáltalán nem jelent hibát, ha egy függvény nem tudja elvégezni a műveletet és false-al tér vissza, tehát ezért nem is kéne exception-t dobjon. (Amúgy dobhatna, és akkor lehetne írni a sok egymásba ágyazott try-catch blokkot, most őszintén, egy szkriptnyelvnél kinek hiányzik ez?)

Ami önmagában is könnyen azt jelentheti, hogy amit nyertünk a réven, azt elvesztettük a vámon, pláne ha olyan API-ról van szó amit sokan és sok helyen fognak használni. De a gond az, hogy ennek oka is van, hogy az auto-kiegészítés nem megy... és ugyan amiatt nem fog menni a refactoring sem rendesen, stb.
Na várjunk, az auto kiegészítés nem döglött teljesen, minden olyan esetben működik, amikor nem futási időben dől el az adott változó típusa/osztálya. Az általam használt nagyméretű framework-nek amúgy ez volt a fő problémája (ami tervezés során került bele és nem tudtunk vele mit csinálni), hogy az objektumok 99%-ánál futási időben dőlt el, hogy milyen típusú. Valószínűleg más nyelvben a típusosság miatt ez a probléma fel sem merült volna, mert ilyen elvek szerint tervezett keretrendszert nem tudtunk volna megírni.

De most tényleg, miféle gondolkodás mód igazolja mondjuk -- hogy egy szándékosan egyszerű dolgot mondjak --, hogy nem hogy nem kell, de nem is lehet a funkció argumentumok típusát deklarálni?
Ez nem teljesen igaz, ugyanis tömbök és osztályok esetén be tudod állítani az argumentumok típusát. PHP-ban a skalár típusok szó nélkül cast-olódnak oda-vissza, így nincs értelme külön specifikálni a függvény argumentumoknál, hogy valami string-e vagy szám, mert egy szám lehet string-ként tárolva, de ettől függetlenül használhatod számként a programodban.

[ Szerkesztve ]

"A php nyelv lazasága miatt sokszor az egyáltalán nem jelent hibát, ha egy függvény nem tudja elvégezni a műveletet és false-al tér vissza, tehát ezért nem is kéne exception-t dobjon.
(Amúgy dobhatna, és akkor lehetne írni a sok egymásba ágyazott try-catch blokkot, most őszintén, egy szkriptnyelvnél kinek hiányzik ez?)"

Először is nyelv tulajdonságaitól ("PHP lazasága") nem függ, hogy egy függvényhívás sikertelensége esetén fontos-e a hiba kezelése (akár a program leállításával), hanem attól függ, hogy a függvényhívásnak mi a feladata. Egyébként érdekes módon én elég ritkán találkozok olyannal, hogy ne érdekelne, hogy sikerült-e egy funkció végrehajtása, pedig nem reaktor vezérléseket írok vagy effélét... Másodszor, a kivételek éppenséggel kényelmessé teszik a program írást, rövidebbé, áttekinthetőbbé teszik a kódot. Nagy részben azért is találták ki őket, hogy ne kelljen minden fontosabb funkció hívás után szórakozni a visszatérési érték ellenőrzésével. Ha tudod értelmesen kezelni a problémát akkor írsz hozzá kivétel kezelőt, ha nem, akkor meg nem írsz oda semmit, de akkor sem fog ismeretlen utakat taposva továbbhaladni a program, hanem korrekten leáll (visszatekeri a tranzakciót, stb).

"Na várjunk, az auto kiegészítés nem döglött teljesen, minden olyan esetben működik, amikor nem futási időben dől el az adott változó típusa/osztálya."

Na ja, de pont attól lesz értelme egy "dinamikus" nyelvnek a "statikussal" szemben. Mondjuk OK, ha általában működik a kiegészítés, csak néhány helyen nem (ahol tényleg kihasználod a dinamikusságot), az rendben van. De legalábbis Python területén nekem az a tapasztalatom, hogy komolyabb cuccokban szinte többször nem megy, mint megy... és persze pont ott nem megy, ahol kevésbé vagy jártas (built-in funkciókat tudja fejből az ember, na de vmi komplikált portál-rendszer elvarázsolt objektumainak metódusait...). És nagyon sokszor nem ám azért, mert valami statikusabb rendszerrel megoldhatatlan dolgot csinál az ember, hanem mert pl. sem a funkciók/metódusok visszatérése értéke sem a paramétereik típusa nem deklarált, és innentől kezdve pl. a "valamiParameter." ill. "Utils.getMembershipTool()." utolsó pontja után az IDE jó eséllyel feladja a küzdelmet... Meg hát ugye nekem az is állatira fáj, hogy sokkal de sokkal kevesebb hibát szúr ki az IDE a program begépelés közben (mindent futtatni kell, azt egyesével javítgatni minden félreütést... hú de agile!), na meg a már említett refactoring. Szerintem az ideális az lenne, ha a két tábor kezet fogna végre... miért kell lándzsát törnöm egyik vagy másik paradigma mellett, ha a legtöbb dologra a statikus szigor a jó, és néhányra meg a dinamikusabb megközelítés? Na persze nem kell... pl lehet Java nyelvet (vagy, még szigorúbb: Scala-t) + Groovy-t együtt használni... csak hát az sokszor nem ideális, nyelv alapján "kettétörni" a programot...

"Ez nem teljesen igaz, ugyanis tömbök és osztályok esetén be tudod állítani az argumentumok típusát. PHP-ban a skalár típusok szó nélkül cast-olódnak oda-vissza, így nincs értelme külön specifikálni a függvény argumentumoknál,"

OK, igaz, PHP5 óta (2004), és ha jól tudom csak osztályokat adhatsz így meg, a sckalárok automatikus konvertálódása miatt. De hát ez ismét csak jól mutatja, hogy a készítők mennyire nem értették (talán csak anno, de most mér mit lehet tenni...), hogy miért jó ha deklarált a funkciók típusa. Program írásnál az egyik alapvető dolog, hogy az ember próbál jól definiált "interfészeket" definiálni. Na ezért balgaság nem adni típust funkció paramétereketnek... az automatikus konvertálás megléte irreleváns. (Amúgy maga a PHP-féle auto-konvertálás is megérne egy misét... az afféle túl "okos" konvertálás sok rejtélyes/meglepő hibát tud okozni, tehát főleg ha nem-annyira-profikat is megcélzó nyelvet terveznék, igencsak kerülném az efféle mágiát.)

[ Szerkesztve ]

Egyébként érdekes módon én elég ritkán találkozok olyannal, hogy ne érdekelne, hogy sikerült-e egy funkció végrehajtása, pedig nem reaktor vezérléseket írok vagy effélét... Másodszor, a kivételek éppenséggel kényelmessé teszik a program írást, rövidebbé, áttekinthetőbbé teszik a kódot...
Na ezt kb. úgy oldottuk meg, hogy az osztályos egyes függvényeiben lekezeltük a függvényhívások visszatérési értékeit (ez kis méretű kódnál nem problémás), az osztályaink függvényei viszont már kivételeket dobáltak, amelyeket lekezeltünk. Szerintem egyáltalán nem rosszabb megoldás ez, mint ha kizárólag kivételekkel dolgoztunk volna.

Mondjuk OK, ha általában működik a kiegészítés, csak néhány helyen nem (ahol tényleg kihasználod a dinamikusságot), az rendben van.
Attól függ, hogy írod meg a kódodat. Annyit kéne elfogadni, hogy a php alapvetően szkriptnyelv, ezért nem kell deklarálni a változókat, tehát azoknak nem lehet fordítási időben eldönteni a típusukat. Kb. az összes szkriptnyelv hasonló, és ennek az az értelme, hogy kis méretű programokat elképesztően gyorsan meg tudsz írni bennük. Igen, ebből az következik, hogy nagy rendszerek fejlesztésére kevésbé megfelelőek, de azért figyelmes tervezéssel meglepően sokat ki lehet hozni belőlük. Ebben a részben amúgy tök jól leírtad, melyek az előnyeik az erősen típusos nyelveknek a gyengén típusosakkal szemben, tehát alapvetően igazad van.

OK, igaz, PHP5 óta (2004), és ha jól tudom csak osztályokat adhatsz így meg, a sckalárok automatikus konvertálódása miatt.
Osztályt vagy tömböt. Skalárra valóban nem működik, a tömb azonban nem skalár típus

De hát ez ismét csak jól mutatja, hogy a készítők mennyire nem értették (talán csak anno, de most mér mit lehet tenni...), hogy miért jó ha deklarált a funkciók típusa.
Értették, hidd el, csak olyan nyelvet szerettek volna, amelyben gyorsan lehet dolgozni és könnyen tanulható. Ennek egyik következménye, hogy eredetileg a nyelv abszolut alkalmatlan volt nagy rendszerek készítésére, a másik pedig, hogy boldog-boldogtalan php-ban programozik (vagyis inkább csak gányol), ezáltal a php-vel komolyabban foglalkozó programozók respekt pontszáma nagyon alacsony . Elég csak belenézni a php kérdések topikba..

(Amúgy maga a PHP-féle auto-konvertálás is megérne egy misét... az afféle túl "okos" konvertálás sok rejtélyes/meglepő hibát tud okozni, tehát főleg ha nem-annyira-profikat is megcélzó nyelvet terveznék, igencsak kerülném az efféle mágiát.)
Van egy majdnem kész cikkem a logout-ra a php-s típusokról illetve az az ezek közötti implicit és explicit konverziókról. Tulajdonképpen tartalmilag korrekt, csak kicsit olvasmányossá kell tennem, meg nem tudom, érdekel-e bárkit a téma..
Amúgy pont ez az a témakör, amire nagyon kevés hangsúlyt fektetnek az oktatóanyagok, pedig érdekes és fontos ahhoz, hogy az automata konvertálás ne okozzon semmilyen kellemetlen meglepetést.

"Annyit kéne elfogadni, hogy a php alapvetően szkriptnyelv, ezért nem kell deklarálni a változókat, tehát azoknak nem lehet fordítási időben eldönteni a típusukat. Kb. az összes szkriptnyelv hasonló, és ennek az az értelme, hogy kis méretű programokat elképesztően gyorsan meg tudsz írni bennük."

És ezt pont egy olyan dolog, amit én nem "értek" úgy általában a script nyelvekben, és egyben jól tükrözi ez egész attitűdöt, amit kb úgy szoktam jellemezni, hogy "népszerű, mert szőnyeg alá seperni mindenki szeret". A deklarációs példánál maradva, azzal összességében hol takarítok meg időt, ha nem kell deklarálni valamit? (És ezt ne keverjük azzal, amikor valamit nem lehet deklarálni, mert tényleg dinamikusan lesz eldöntve, hogy létezni fog-e... azt jó ha lehet, ha tényleg kell adott probléma elegáns megoldásához.) Persze, azzal hogy nem írtam oda, hogy, mondjuk "var" (vagy hogy "int", ha a típust is deklarálni kell) kevesebbet gépeltem, de hol éri meg, hogy emiatt kevésbé látszik ránézésre, hogy milyen változóim vannak (és hogy azok milyen típusúak!), meg hogy ha véletlenül elírok valamit akkor nem derül ki azonnal? Pláne értékadásnál tudok ettől frászt kapni... pl heigth = 100 (v.é., el van gépelve a változó név) sok script nyelven még futásidőben sem hiba, mert lazán létrehoz egy új változót... sőt, soknál akár mezőket is lehet így kreálni. Ezeken mind veszíti az ember az időt (meg a hajat...), mind ezt lényegében azért, hogy -- hasra -- 25%-al kevesebbet gépeljen? Nyilván, néhány soros programoknál kutyát nem érdekli ez a deklarálós gond, de basszus, melyik valós életben előforduló program akkora. Shell script-ek kb, meg némi "glue code" itt-ott... oda való az ilyesmi nszvsz.

Amúgy a dinamikus nyelvek valós előnyei manapság szerintem jó részben annak köszönhetőek, hogy a statikus nyelvek világa eléggé lassan mozog... Pl, hogy a fenti téma egy mellékhajtására utaljak, type interference-el sok idegesítő típus deklaráció elkerülhető. Arra meg, amire lényegében a meta-programozással meg duck-typinget használjuk, ugyancsak lehetnek megoldások egy statikus nyelvben (lásd C# extension methods, vagy Scala implicit conversions, de akár a mixin-ek is idesorolhatóak, meg általában egy fejlettebb típusrendszer)... Ha a mainstream statikus nyelvek mögött annyi "láng" lenne mint sok dinamikus mögött (szemben a konzervatív "enterprise stílussal") már aligha lenne ekkora igény a dinamikus nyelvekre.

[ Szerkesztve ]

Jó lett a lap, grat!

Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak