- Amazfit Active 2 NFC - jó kör
- Azonnali mobilos kérdések órája
- Google Pixel 8a - kis telefon kis késéssel
- iPhone topik
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Fotók, videók mobillal
- Google Pixel topik
- One mobilszolgáltatások
- Android alkalmazások - szoftver kibeszélő topik
- Milyen okostelefont vegyek?
Új hozzászólás Aktív témák
-
ddekany
veterán
Én itt csupán annyit akartam kifejezni, hogy Java ill. C# esetén a kérelmeket túlélő állapotot természetes, és nem kell hozzá kiegészítő. Illetve leírtam hogy ez mihez elég, és mihez nem. Nem mondtam hogy teljesítmény = skálázódás, meg hogy jaj de szar ezért a PHP (másért az). Meg persze a "shared nothing" elv nem a PHP sajátja, szóval itt inkább azon lehetne vitatkozni, hogy a "shared nothing" hova jó.
Amúgy ez osztott állapotos dolog script nyelveknél jellemzően nem úgy működik mint Java/C# esetén, mert a "hivatalos" megvalósítás általában nem támogatja a több szál párhuzamos futtatását ugyan azon folyamaton belül (Python és Ruby sem, bár vannak alternatív megvalósítások, mint Jython és JRuby). Ez vonatkozik az említett Node.js-re is tudtommal. Ha jól tudom úgy néz ez ki, hogy indítasz egy szerveren mondjuk 5 db node.js folyamatot, ha azt akarod hogy ki tudja használni a 4 fizikai magot, és ezek a folyamatok nem osztoznak (közvetlenül) az állapoton.
Azt meg nem fogom, miért zavarna engem, ha PHP-n belül fut V8... Akkor az ECMAScript, szóval onnantól már az a kérdés, hogy mit szólok az ECMAScripthez.
-
cadeyrn
aktív tag
Hopp, amit kifelejtettem némi magyarázatot.
A PHP session túlél minden kérést, és ugyanaz van benne, amíg él. Annyi, hogy kell a kód legelején egy session_start().
Egy session cookie nevű dologhoz kötődik a user gépén, ezzel azonosítja a PHP (!), hogy melyik helyileg mentett file adatai tartoznak az adott kéréshez. (Igen, lehet hijackelni, sajnos) Általában cron törli a szerveren, nem teljesen automatikus, szóval akár örök életű is lehetne.No ez az az elem, amit lehet memcached poolban tárolni, és akárhány webszerverről közösen elérhető. Értsd: mindegy, hogy a loadbalancer a usert melyik webszerverre dobja be, mert ugyanaz a session, már megvannak az adatok róla.
Ergo lényegtelen, hogy a program újraépül, a sessionben ott az adat, ami kell.
Mi is hiányzik?
-
Pont ezert irtam lentebb, hogy eleg keves programozo tudja rendesen kihasznalni az osztott es/vagy perzisztalt allapotot. A PHP meg pont azert skalazodik, mert mindig mindent ujraepitesz (skalazodas!=sebesseg), egy memcached-t meg barki fel tud loni, ha arrol van szo.
(Disclaimer: nem vagyok php-programozo, sot, webprogramozo sem, hala az egnek.) -
cucka
addikt
Majd egyszer valaki ír egy node.js-t php alá és akkor az is fog napokig futni.Én már írtam php-ban rendes gtk-s alkalmazást, az sem lépett ki klikkelésenként. (Ok, igazából erre a feladatra elég pocsék a php nyelv, csak annak idején azt mondta a tanár, hogy értékeli a szokatlan megoldásokat
)Egyébként meg tessék, V8 engine php alá, lehet kezdeni ismét a rettegést meg a szörnyülködést
-
cadeyrn
aktív tag
PHP-ben nincs main függvény. Lehetne, és futhatna végtelen ciklusban egy while(1)-el, csak az az alapműködést borítja meg. Ez az óriási különbség a C++, C#, Java és a többi klasszikus programmal szemben. A PHP-ben nem az alkalmazás a démon, hanem fordító, szóval nem biztos, hogy fair ezt felróni ellene.
http://www.phpcompiler.org/
https://github.com/facebook/hiphop-php/wiki/
Ezekkel le lehet fordítani a PHP kódot, hogy klasszikus program készülhessen belőle. -
ddekany
veterán
"PHP tud sessiont memcached poolban tárolni. Tény, kell hozzá Memcached extension, de mi is egy extension?"
Az eltérés, hogy Java/C# esetén természetes, hogy több kérelmet túlélhetnek objektumok. Nem kell hozzá kiegészítő, és teljesen áttetsző az egész, mivel ez az alap felállás.
"se Bash se pl. a Perl nem fordít köztes kódot, pont a Python a kivétel. Szerintem."
Python csak annyiban kivételes, hogy ott bevett szokás ezt fájlban is letárolni (pyc). De az nem extrém dolog, hogy egy "script nyelv" valamiféle byte kódba fordul futás előtt.
-
SlipOne
csendes tag
Említettétek itt az arckönyvet, amiben a php kódot átfordították "natív" c -s kódra.
Ilyet melótárs is csinált, lassú volt egy zend-es implementáció, amit php-ben írtak (amf szérializáció volt ha jól emlékszem). Úgy gondolta segít rajta, ha átírja c-re és befordítja "natív php" kódra, aztán azt kitesszük a vps-re. Hát volt értelme, minimum 20x gyorsabb futást eredményezett azon a területen.Mindezek alapján ha rengeteg időnk lenne és nem kéne a rendszert 999x újraírni (a vezetőség "átgondoltsága" miatt), akkor simán érdemes átírni c-re, azt befordítani és utána futtatni. Kb ezt csinálta az arckönyv is, így elég masszív alkalmazásokat lehet írni php-n, bár ez már korántsem az igazi, alap php, pláne, hogy ilyet egy tárhelyen sosem fogsz futtatni.
-
cadeyrn
aktív tag
Mainframe téma: HP disaster proof data center
-
cadeyrn
aktív tag
PHP tud sessiont memcached poolban tárolni. Tény, kell hozzá Memcached extension, de mi is egy extension? Ugyanolyan kiegészítő mint pl. a swing a Java-nak.
Az állapottér mentése weben tényleg nem a nyelv, hanem a sw (és a keretrendszer) feladata szerintem is.
Köztes kód? APC ami kb. egyidős a PHP-val, csak nem "kötelezően" része, mindössze modulként bármikor hozzákapcsolható. A köztes kód egyébként szerintem pont, hogy normális egy scriptnél, se Bash se pl. a Perl nem fordít köztes kódot, pont a Python a kivétel. Szerintem.
-
cucka
addikt
Pont mert a PHP erre nem képes alapból/kényelmesen, nagyobb rendszereknél kezd kínos lenni, hogy minden egyes beérkező kérelemnél újra és újra felépít mindent a kályhától indulva.
Alapból egyik nyelv sem képes rá, 3rd party kiegészítőkkel (vagy saját kód írásával) meg bármelyik képes rá. Igen, még a php is, és nem kell hozzá semmiféle voodoo varázslat, én is fejlesztettem már ilyen keretrendszert.A valamire való script nyelvek valamilyen köztes kódra fordulnak futás előtt, amit viszont el tudsz menteni ha nagyon akarod
Igen, sajnos ez tényleg hiányzik a php alapszolgáltatásai közül, külső eszközökkel viszont meg lehet oldani, szóval ez sem probléma. -
ddekany
veterán
"Weboldalak fejlesztésénél az állapottér mentése valamilyen session azonosítón keresztül történik - ez a http protokoll következménye, tehát független a programozási nyelvtől."
Ez nem így működik. A session-t, mivel a látogató tevékenységéhez kötődőik és nem reprodukálható, persze illik menteni HDD-re. De csomó dolog van, ami újra felépíthető ha újraindítod az alkalmazást, csak épp az időbe telne. Lehet itt gondolni tipikus cache-ekre, pool-okra, de akár egy rakás összetett akármire, aminek rakás konfigurációs fájlt meg osztályt be kell olvasnia, hogy elinduljon, stb, szóval nem két pillanat, amíg feláll a semmiből. Pont mert a PHP erre nem képes alapból/kényelmesen, nagyobb rendszereknél kezd kínos lenni, hogy minden egyes beérkező kérelemnél újra és újra felépít mindent a kályhától indulva.
"Az alap php-t nem tudod lefordítani, mint ahogy semmilyen scriptnyelvet nem tudsz alapból, mivel ezeknek pont az a lényegük."
A valamire való script nyelvek valamilyen köztes kódra fordulnak futás előtt, amit viszont el tudsz menteni ha nagyon akarod (pl. Python így is csinálta: py -> pyc). Általában nem akarod. De még cache-elheted is memóriában a köztes kódot, és akkor nem kell hozzá fájlokat gyártani.
-
FTeR
addikt
mi köze a http-nek ahhoz, hogy a session-t hol tárolja?
asp.net-ben pl 3 van:
- inprocess
- state server
- sql serverconfig kérdése. ha sql server-be rakod, akkor az sql server képességeinek megfelelően tudod skálázni. előnye még, h egy server restartot is túlél a session.
#166
ezt az érvrendszert gondold újra. komolyan azzal akarsz érvelni, h php az a környezet ahova nem kell 3rd party? 3rd party nélkül a php konkrétan használhatatlan. -
cucka
addikt
ez az alap php-ban értelmes eszközökkel kezelhetetlen probléma, míg jáva ee-ben alapból ott van és kezeli a teljes ecosystem load balancer frontendtől kezdve appszerverrel bezárólag.
Önmagában az alap Java nyelv lóf*szt ment, nem állapotteret. A Java ökoszisztéma valamilyen framework-el már menti az állapotteret, de hát innen nézve a php is tudja pontosan ugyanezt. A Java nyelv önmagában kevés dologra jó, az aduásza egyértelműen a tool-ok sokasága - a php előnye itt az, hogy ez egy webre készített template nyelv, tehát alapból olyan eszközökkel jön, amelyeket más nyelveken 3rd party tool-okban implementáltak csak, plusz ugye 3rd party tool-okból itt is tele a padlás.Annak a php-nak, amit az arckönyv használ, van bármi köze az eredeti php-hoz? mert itt olyan hírek szállingóztak, hogy nagyon átdolgozták az egészet
100%-os pontossággal nem tudom, de legjobb tudomásom szerint saját maguknak fordítják/hekkelik a php-t, plusz ugye ők fejlesztették a "php fordítót" is.
Nekem amúgy úgy tűnt, hogy a php-val igazából nem jártak túlzottan jól, ekkora méretű rendszernél, mint az övék, nem egyszerű php alapon szolgáltatni, szívtak a skálázódással is, stb.. -
bambano
titán
nem azt kérem számon, hogy miért nem menti a php az állapotteret, hanem azt, hogyha megkérdezed, hogy miért gagyi a php és választ kapsz a kérdésre, akkor a válaszolás tényén minek kell kiakadni.
miért is mentse a php az állapotterét? mert az alkalmazásoknak szokott olyanjuk lenni, azért. ez az alap php-ban értelmes eszközökkel kezelhetetlen probléma, míg jáva ee-ben alapból ott van és kezeli a teljes ecosystem load balancer frontendtől kezdve appszerverrel bezárólag. Hát ezért gagyi a php, minimum a jávához képest.
Annak a php-nak, amit az arckönyv használ, van bármi köze az eredeti php-hoz? mert itt olyan hírek szállingóztak, hogy nagyon átdolgozták az egészet... ráadásul az arckönyvben alapvetően rövid, egyszerű tranzakció zajlik, de abból sok. Ezt simán lehet úgy skálázni, hogy hordod be a vasat a szobába, valamelyik majd csak kiszolgálja azt a kérést. Egy bonyolultabb alkalmazásnál ez nem működik rendes nyelvi eszközrendszer nélkül.
-
cucka
addikt
a jól skálázódásnak feltétele lenne az állapottér mentése, ami, tudtommal, sem alap php-ben, sem a hozzá gyakran használt webszerverekben sincs meg.
Ez jól hangzik, de
- Azt kéred számon, hogy a php program miért nem menti el a saját állapotterét 2 futtatás között. Ez nonszensz.
- A http alapból állapotmentes protokoll. Weboldalak fejlesztésénél az állapottér mentése valamilyen session azonosítón keresztül történik - ez a http protokoll következménye, tehát független a programozási nyelvtől.ergo php egyáltalán nem alkalmas skálázódó webszervizek írására.
Alapból valóban nem a legjobb webszervízre, de vannak eszközök, amelyek segítségével azzá tehető, mondjuk ott a Facebook, akiknek sikerült megoldani. (Bár ekkora méretű rendszereknél valószínűleg tényleg kevés az, amit a php nyújt )az meg pazarlás, hogy alap php-t mindig újra kell fordítani.
Az alap php-t nem tudod lefordítani, mint ahogy semmilyen scriptnyelvet nem tudsz alapból, mivel ezeknek pont az a lényegük.
Egyébként meg ezt is lehet cache-elni, sőt, le is fordíthatod a php kódot úgy hagyományosan. -
-
floatr
veterán
Itt már rég nem arról van szó, hogy a nyelv tervezési metodikája hogyan formálja az egészet, mert egy bizonyos szint után már az ökoszisztéma a meghatározó. Ha azt nézed h a C++ mekkora kínlódás az ATL környékén, akkor ahhoz képest hihetetlen megkönnyebbülés a QT-alapú fejlesztés.
Visszakanyarodva a topichoz nekem bejön a JS ilyen irányú "fejlesztése", bár az ES4 szimpatikusabb volt. Kifejezetten jó elképzelés volt több szempontból is, kár h elhalt a dolog
-
FTeR
addikt
egyértleműen C#. ha végigköveteda nyelv fejlesztését, egyértelmű, hogy az legelejétől kezdve erős koncepció mentén haladnak, új fícsöröket mindig a meglévő bázis függvényéáben implementálnak.
ne értsük félre, mint #148, ez önmagában nem jelenti azt, hogy a világ legjobb nyelve, minden tökéletes benne, hibátlan és mindenkinek ez a kedvenc nyelve.
ez azt jelenti, hogy az alap koncepciót elsajátíva képes vagy felhasználni a tudást új fícsörök elsajátítására. ha a koncepció egységes és ismered azt a koncepciót, akkor a dokumentáció bújása nélkül képes vagy számodra új fícsört/függvényt használni.
ezzel szemben php-ban még nagyobb rutin mellett is rendszeres látogatója vagy a php.net/manual-nak.js meg egyértelmű, tény, hogy egy alpha verzió került netscape-be, ami a csoda folytán túlélte a történelem viharait és azóta is szívunk vele. viszont jól jelzi a rugalmasságát, hogy mindne problémája ellenére a különböző famework-ök segítéségre miylen sokra vitte.
-
ddekany
veterán
"ergo php egyáltalán nem alkalmas skálázódó webszervizek írására."
Memcache és társai... persze bénák ahhoz képest, mint ha vannak valódi hosszú életű objektumaid.
"az meg pazarlás, hogy alap php-t mindig újra kell fordítani"
APC és társai ezért vannak. Persze először én is nagyon csodálkoztam, hogy ez nem alap.
-
-
bambano
titán
a jól skálázódásnak feltétele lenne az állapottér mentése, ami, tudtommal, sem alap php-ben, sem a hozzá gyakran használt webszerverekben sincs meg. ergo php egyáltalán nem alkalmas skálázódó webszervizek írására.
az meg pazarlás, hogy alap php-t mindig újra kell fordítani.
-
ddekany
veterán
Egyrészt ezek ált. később jöttek mint amit ki kéne ütniük. Mint mondtam, szükségszerűen tanulunk belőle, ha használunk egy nyelvet, a következő így (remélhetően...) jobb lesz.
Másrészt, jókor, jó helyen, megfelelő fókusszal/marketinggel, megfelelő nagy céggel mögötte... ezek fontosak, és egyik sem függ a nyelv tervezési minőségétől. Pl. lehet hogy ha, tényleg csak hasra, anno a Python elkezd fókuszálni a shared hostingra és az alacsony belépési korlátos (vagy mi ez magyarul) webes programozásra, akár némi kompatibilitási törés árán, akkor most az lenne nem PHP. De hát mással voltak elfoglalva...
-
FTeR
addikt
az érved ott megdől, h php már rég nem arra van hazsnálva, amire kitalálták.
a php egy perl klón script nyelvnek indult és mindenféle koncepció nélkül kapaszkodott fel webserver OOP-ig.
a probléma a koncepció hiányával és verziókezeléssel van. ez legjobban a függvénynevekben követhető, mint a pl mysql_real_escape_string, mert az eslő verzió nem sikerült elég real-re. a string függvények jó példák még, ugyanarra a feladatra van 6 függvény, amik 6 féleképpen kell meghívni és egyik sem igazán jó.összehasonlításképpen, a C# is egy bloatware, ami nincs leragadva egy metodikánál, mégsem akkora káosz mint php.
-
ddekany
veterán
Egyrészt nem szükségszerű, hogy legyen olyan nyelv... de történetesen vannak a mainstreamoknál lényegesebben jobban megtervezettek. Példa... Digtal Mars D, Ruby, akár kicsit Python is (báááár ott már kezd gyűlni a szar). Ceylon is szerintem nagyon ígéretes mint nyelv, persze az esélyei még a Red Hat-el mögötte is igen csenevészek. Scala is elég komoly darab (bár egy fatális benézés van ott is szvsz...).
A másik... idővel bölcsebbek leszünk, jobb nyelveket készítünk. Csak a régiek mögött ott van a nagy múlt, így nehéz őket kiütni. Ettől lesznek ált. a mainstream cuccok elavultak/bénák. Nem ám azért, mert én valami extra negatív ember vagyok, akinek semmi sem jó.
-
#148
floatr
veterán
fordfairlane
#144
floatr
veterán
válasz
fordfairlane
#144
üzenetére
Szerinted
Szvsz már a VB-ből eredező névadási konvenciónál kezdődik a probléma -
#147
fordfairlane
veterán
ddekany
#145
fordfairlane
veterán
-
#146
cadeyrn
aktív tag
fordfairlane
#144
cadeyrn
aktív tag
válasz
fordfairlane
#144
üzenetére
Nem tőled, a "Ha nem akarunk úgy járni, mint PHP-vel, sőt a C/C++-al, jobb vigyázni." mondat után lennék kíváncsi, melyik nyelvet tervezték meg jól.
-
#145
ddekany
veterán
fordfairlane
#142
ddekany
veterán
válasz
fordfairlane
#142
üzenetére
"A valóság néha bekopogtat az idealisták ajtaján"
Ez egyáltalán mit jelent... Én is mainstream nyelveket használok, leginkább (PHP, Java). Csak ha valami eszmefuttatás közepén valaki elejti, hogy a X szar nyelv, akkor nem én kezdek el vele végtelen ciklusba futni, hogy de juj juj miért kell "fikázni"... Eleve miért fika ha valaki a nevén nevez dolgokat, na de mindegy...
-
#142
fordfairlane
veterán
ddekany
#141
-
#141
ddekany
veterán
fordfairlane
#140
ddekany
veterán
válasz
fordfairlane
#140
üzenetére
Ha nem szereted a rinyát, ne rinyálj. Miért zavar ennyire sokakat, ha kijelentek valami egyszerű tényt... a PHP nyelv egy rakás szar. Pont. Tény. Nem kell rá visszaszólni, ha "jaaaj mirét kell mindíg" stb.
"Tkp. minden szar, amit sokan használnak."
És ez így is van. Mert nem működik az érdem szerinti szelekció... annyira. Nem tudom miért ilyen nehéz ezt felfogni. Van valami fizikai törvény, ami miatt ez képtelenség? Nincs.
-
#140
fordfairlane
veterán
ddekany
#139
fordfairlane
veterán
Hogy micsoda károkat okoz a C++, meg a PHP, meg úgy minden, amit emberek csináltak, nos, ezt hívhatjuk igényességnek, nézőpont kérdése. Csak engem már zavar a sok rinya.
Hopp, a JAVA kimaradt, pedig egyes igényesek szerint abban is van ám szar. Tkp. minden szar, amit sokan használnak.
-
#139
ddekany
veterán
fordfairlane
#137
ddekany
veterán
válasz
fordfairlane
#137
üzenetére
És van akit meg zavar, ha a másikat mélyebben érdekeli a szakmája és ezért igényesebb... Sok komplexumos ember...
-
ddekany
veterán
Ha csak teljesen földhözragadt gyakorlati jelentőségét nézzük a dolgoknak, jó lenne, ha nem kövülne bele örökre a civilizációnkba ez a szar (is), hanem egyszer kiváltaná valami jobb. És de igen, számítana. Ez nem fog megtörténni valószínűleg soha, de ha meg fog, ahhoz kellett, hogy ne legyenek annyira sötétek a programozók, hogy nem látják a "tetvezők" (
) által elkövetett hibákat, ami igenis az ő idejükbe kerülnek a végén.Az egész pont így kapcsolódott a témához (JavaScript/ECMAScript VS új valami nyelvvel próbálkozás) amúgy... Ha nem akarunk úgy járni, mint PHP-vel, sőt a C/C++-al, jobb vigyázni.
-
cucka
addikt
Te azt állítottad, hogy a php tervezése során sok hibát követtek el és ezért ez egy rossz nyelv, aminek széleskörű elterjedése káros.
Szerintem meg a php tervezése szerint sok hibát követtek el, ennek ellenére ez egy nagyon hatékony eszköz arra, amire kitalálták és fölösleges károgni azon, hogy ez mekkora károkat okoz, mert nem okoz. -
bambano
titán
-
cucka
addikt
nyelv? programozik még valaki csupasz nyelven, pl. php-ban webes alkalmazást?
Szerintem nem nagyon, de a téma az volt, hogy milyen rosszul megtervezett nyelv a php, ezért nem ökoszisztémáról írtam. Ha a feladat "gyorsan egyszerűt" jellegű, akkor a php ökoszisztémával együtt is ott van a szeren.nekem a woodstock. még akkor is, ha régi.
Vagy én vagyok béna, vagy ez olyan régi, hogy nincs túl sok nyoma a neten . Tudnál adni valami linket erről?hát ja, ez meg is látszik a deface helyezési listával foglalkozó weblapon
Igen, sok gyenge minőségű weblap van. Na és? Kis pénz, kis foci. -
bambano
titán
"melyik az a nyelv, amiben kevés munkával, gyorsan lehet egyszerű weboldalakat és webes szolgáltatásokat gyártani?": nyelv? programozik még valaki csupasz nyelven, pl. php-ban webes alkalmazást?
én inkább azt kérdezném, hogy melyik az az ecosystem, amiben...
nekem a woodstock. még akkor is, ha régi.egyébként "boldog-boldogtalan szeretett volna magának egy egyszerű honlapot": hát ja, ez meg is látszik a deface helyezési listával foglalkozó weblapon
-
cucka
addikt
Nem értek veled egyet. Szerintem a programozási nyelveknek nincs szent grálja - az, hogy egy nyelv mennyire hatékony, azt nem a nyelv tervezése során elkövetett hibák száma mutatja. Például php-ban és C-ben is lehet hajmeresztő dolgokat írni, számtalan módon lábon lőheted magad, mégis, az egyik nevetség tárgya, a másik meg egy fantasztikusan jól megtervezett nyelv.
Korábban már leírták: a php népszerűségének kulcsa, hogy jó időben volt jó helyen. Az internethasználat robbanásszerűen növekedett, boldog-boldogtalan szeretett volna magának egy egyszerű honlapot, ilyen feladatokra pedig szerintem a php a mai napig a legjobb eszköz.
Van egy olyan tényező is, hogy a legjobb programozó is kevesebb munkával tud ugyan olyan jót alkotni egy jobban megtervezett nyelvben.
Na, és melyik az a nyelv, amiben kevés munkával, gyorsan lehet egyszerű weboldalakat és webes szolgáltatásokat gyártani? Szerintem jelenleg a php az, de várom az alternatívákat -
cadeyrn
aktív tag
de ettől az még jobb volt, mint a pc-k.
Ez így van. Sok tekintetben még mindig jobbak, ezt nem is vitattam. Csak azt, hogy az egy nagy gép a sok kis, kaptárszerű géppel szemben avult el - szerintem. A gond az, hogy míg az elsőt erre tervezték a második kvázi kialakul, és sok minden fokozatosan - sokszor rossz irányból - alakul csak ki hozzá. Lehetne a cloudot jól csinálni, de ahhoz valakinek tervezni kellene erre egy komplett megoldást, oprendszerrel, kitalált struktúrával, stb., ennek viszont azért nem igazán van realitásalapja, mert míg mainframe-et eladásra szántak, cloudot szolgáltatásnak.
A rendszer meg... a linuxot korrekt rendszernek tartom, de olyan távolról integet a tényleg stabilitásra alkotott rendszereknek, hogy az ijesztő.
Érdekes egyébként, hogy a mainframe-mel kapcsolatban ott mindenki a teljesítményt említi, amit igazából teljesen logikus "kiszerverni" pl. a Boinc elvén. Viszont a stabilis, az sajnos a veszteség listán szerepel, mind áldozat, legalábbis a fizikai.
Meg kell tudni oldani software-ból, tranzakciókkal, hibakezeléssel, mert a vasra és a rendszerre sokszor nem is engedik már, hogy támaszkodj. -
bambano
titán
persze, mindig mindent meg lehet oldani másképp, csak ezen másképp megoldások közül van, ami tisztességes megoldás, van, ami gányolás.
ez kb. olyan, mint az adblue. nem tudunk rendes dízelmotort gyártani, ezért elkezdjük körbehekkelni a hibáit.
a rendes grafikus felületre meg szükség lenne, mert ha mégse, akkor a má$ik világ miért erőlködik annyira, hogy neki is legyen? lásd: citrix terminálszerver.
(#126) cadeyrn: az ár mindig is egy valós indok volt a mainframe-k ellen, mit vársz egy olyanm cégtől, amelyik utcán, boltban vásárolt modemet rak a marsra küldött szondáiba... meg űrnagyhatalom, űrjármű nélkül...
egyébként (lehet, nem látszik), nem akarok kardoskodni azért, hogy terjedjen jobban a mainframe, pusztán szeretném bemutatni, hogy a mainframe anno sokkal fejlettebb volt, mint amit sokan hisznek róla. én sem hiszem, hogy a 800-1000 ezer forintos pc szerver helyett töménytelen mennyiségű főkeretet fognak venni többszáz misiért. de ettől az még jobb volt, mint a pc-k.
-
"tudsz pl. [blablabla]".
Nem tudsz, mert nincs ra szukseg. Mas a filozofia, masok a megoldasok, az elonyok es a hatranyok. Nem fogsz oprendszert cserelni a futo vason mondjuk a Google-nel, mert legfeljebb betolsz egy masik gepet masik oprendszerrel, igazabol tokmindegy az oprendszer. CPU mikrokodot sem cserelsz, mert az is mindegy. Halozattranszparens grafikus felulet megint ROTFL indok, szinten nincs ra szukseg, otvenfelekeppen meg lehet oldani a tavoli menedzsmentet ezen kivul.
Persze lehet magyarazni, hogy bank igy-ugy-amugy, a valos helyzet az, hogy pont a nagy bankok menekulnek a mainframe-ekbol, ahogy tudnak.
-
cadeyrn
aktív tag
Azok pedig magát a vms-t nem borítják meg
Nem, azt valóban nem, rendszer alatt a komplett szolgáltatást értettem, elnézést.Az elosztott rendszerek stabilitásával még mindig az a baj, hogy ha meghalt a vas, akkor a rajta futó aktuális processzek elpusztulnak. Meglepődnék, ha processz szinten redundáns lenne a cloud. A cloud szolgáltatás szinten redundáns, tehát ha lepusztul egy darabja, akkor az adott tranzakciórészt újraindítva elvégzi a kiszolgálást. Tehát ha rácsatlakozol egy nagy webszájtra és pont az a node borul le, amire csatlakoztál, akkor a load balancer újrakéri az url-t egy másik node-tól, amit te észre sem veszel. Ettől az adott processz állapottere még ment a levesbe.
Ezzel valóban nem kalkuláltam. Process rendundanciát még nem is láttam sehol megvalósítva.
-
ddekany
veterán
"Sőt, szinte minden scriptnyelv ilyen."
Egy "script nyelv" is tehet egyet és mást a karbantarthatóságért/megbízhatóságért. Pl. az inicializálatlan változók olvasását egyáltalán nem kell hagyni. Sőt, a deklarálatlanok írását sem muszáj hagyni. Az automatikus típus konverziókat is lehet ésszerű keretek közt tartani. Nem kell mindent egy közös névtérbe bedobálni sem (hanem lehet valami modul/package rendszer). Nem kell visszatérési értékeket használni hibajelzésre (mert elfelejti ellenőrizni a programozó, aztán fut tovább ismeretlen vágányon a program). Stb, stb.
Mellékesen a PHP a fentiek közül minden ilyen hibát elkövetett, sőt olyanokat is, amiket máshol még tán nem is láttam (pl. ha több paraméterrel hívsz egy függvényt, mint ami van neki, annak semmi nyoma), aztán utólag próbálják ezeket enyhíteni (error_reporting beállítások pl). Mit lehet ezek után a készítőkről gondolni...
-
bambano
titán
"Nézőként ill. a storyk hallgatójaként annyit tudok, hogy amikor pl. portolták a unix eszközöket, a VMS stabilitása is billent, ergo a unix eszközökkel volt a gond, nem az ősrendszerrel, ilyenekre gondoltam, amikor azt mondtam, csak a saját rendszereivel annyira atombiztos"
ez egy teljesen értelmezhetetlen, ámde hamis mondat.
mik azok a unix eszközök, amiket portoltak? a vms szempontjából felhasználói programok, semmi más. Azok pedig magát a vms-t nem borítják meg, mint ahogy ezen a fórumon, más topicokban többször elhangzott vélemény szerint ha az alkalmazás miatt felborul az xp, azért nem az xp a hibás.Egyébként nyugodj meg, senki nem borogat fel semmit. Nekem is csak egyszer sikerült hanyatlökni egy vaxot, de akkor ki kellett kapcsolni
Az elosztott rendszerek stabilitásával még mindig az a baj, hogy ha meghalt a vas, akkor a rajta futó aktuális processzek elpusztulnak. Meglepődnék, ha processz szinten redundáns lenne a cloud. A cloud szolgáltatás szinten redundáns, tehát ha lepusztul egy darabja, akkor az adott tranzakciórészt újraindítva elvégzi a kiszolgálást. Tehát ha rácsatlakozol egy nagy webszájtra és pont az a node borul le, amire csatlakoztál, akkor a load balancer újrakéri az url-t egy másik node-tól, amit te észre sem veszel. Ettől az adott processz állapottere még ment a levesbe.
-
cadeyrn
aktív tag
nagyon off
Ez esetben bocs a kisregényezésért, teljesen úgy emlékeztem, a Metagalaktikában így emlegették.kevésbé nagyon off
Nem akartam kikezdeni senki tudását és ismereteit, vaxot én csak nézőként éltem meg.Nézőként ill. a storyk hallgatójaként annyit tudok, hogy amikor pl. portolták a unix eszközöket, a VMS stabilitása is billent, ergo a unix eszközökkel volt a gond, nem az ősrendszerrel, ilyenekre gondoltam, amikor azt mondtam, csak a saját rendszereivel annyira atombiztos.
Tudom, hogy sosem fog stabilitásban versenyre kelni egy PC egy mainframe-mel (a HP DL széria pl. bőven PC) - ha önmagukat hasonlítjuk.
Ellenben ha egy komplett elosztott rendszert mérsz össze egy mainframe-mel, ott már néha érezni hasonló képességeket - stabilitásban, mivel annyi redundancia van már benne.Az viszont, hogy nincs bottleneck... azért függ az az átfolyó adatmennyiségtől, szerintem.
Tényleg, kérdés: honnantól számoljuk a mainframe-et?
még kevésbé nagyon off
A PHP ilyen. Sőt, szinte minden scriptnyelv ilyen. Azért script, hogy ne fájjon a típusokkal bajlódás Ott a lua, ami beágyazható: nem típusos, nem is szépen struktúrált, script, mégis piszok hatékony.Az, hogy nem arra használják a PHP-t, amire egykor kitalálták - ez van. Kényelmes, gyors, és ma ezt fizetik ki, a vas olcsóbb, mint a jó programozó.
-
bambano
titán
A legyőzhetetlen nem kisregény, hanem teljes regény, de mindegy. Ilyenkor szokott kiderülni, hogy már akkor olvastam, amikor az ajánlója még pelenkás volt
"Azonban 1 db mainframe sosem fog katasztrófatűrő lenni": mi is akadályoz benne, hogy az legyen? Hint: semmi. Escon kapcsolatot lehet 60 kilométerre is vinni, ha nem hagyják kipusztulni a ci-t, valószínűleg megoldották volna, hogy azt is lehessen wan-on használni.
"nem lesz redundáns": nem, persze. Azért nem lesz redundáns, mert eleve az, már, múlt időben. Mondj már egy pc-t, ami szemrebbenés nélkül túléli, ha kipusztul belőle egy vinyóvezérlő...
"borzasztó drága": ez igaz. eddig ez az egyetlen valós érvetek az mf ellen.
"Csak a saját vasát/programját eszi meg": ajjajj, most szólsz, hogy azt a rengeteg cuccot, amit ráraktam, vagy azt a mégrengetegebb cuccot, amit Maulis kolléga rárakott a ludensre, azt nem is lehet rátenni? Nehogy visszavonják a régi fizetésemet meg jutalmamat, mint egyszeri államfőnek a doktorátusát, mer' abba beleszakadok...
az kétségtelen tény, hogy hardvert nehézkes volt vaxba mástól venni, nem lehetetlen, csak nehézkes. De pl. nagy sun gépekbe volt sok másodgyártó cucca is, több esetben jobb, mint az eredeti.
hát például vannak nyelvek, amikben nem fordul le a program, ha nincs minden változó inicializálva. Ehhez képest a php nemhogy vidáman elfutkározik inicializálás nélkül, még azon se akad fel, ha menet közben típust vált a változód. Na aztán találd ki, hogy ha idegen kóddal kell interfészelni, akkor az ott micsoda és kivel van...
a mysql cli-t nem szokták weben keresztül hekkelni.
Közben nekem is forgott az agyam a kérdésen, és rájöttem, hogy mi a fő különbség a főkeret meg a pc között: a főkeretben nincs bottleneck. Azoknál az alrendszerek bírják a terhelést, nem úgy, mint a pc-ben, ahol egy proci rohadt gyorsan vár a memóriára meg a perifériára meg ilyenek.
-
bambano
titán
ha egy programnyelven megírt program helyességét elvileg sem lehet bizonyítani, mert olyanok a nyelvi eszközök, akkor az a programnyelv rossz.
a magam részéről még azelőtt félbeszakítom ezt a threadet, mielőtt eljutunk a kell-e diploma subthreadig
fentiek nem zárják ki, hogy vidáman használd a php-t vagy bármi mást, meg azt sem, hogy saját elméleteid szerint javítsd a saját kódolási szokásaidat.
-
ddekany
veterán
válasz
Cathfaern
#115
üzenetére
"PHP-ba is nagyon sok dolog utólag lett belehegesztve"
Illetve, a PHP ezt a probléma típust még egy szinttel tovább vitte, nevezetesen a készítők rajta tanultak programnyelvet tervezni/készíteni... vagy legalábbis nagyon úgy néz ki. Csak végig kell nézni a változásait a kezdetektől.
Kéne valami törvény, hogy nem ér olyan nyelvet használni tömegesen, aminek a készítőinek nincs 20+ év előélete a témában...
"Persze az igaz, hogy a legszarabb nyelvben is lehet jó programot írni, de sokkal jobb, ha már a nyelv is kikényszeríti ezt"
Van egy olyan tényező is, hogy a legjobb programozó is kevesebb munkával tud ugyan olyan jót alkotni egy jobban megtervezett nyelvben. Mint mindenhol máshol is, jobb munkaeszközökkel jobban megy a munka tudástól függetlenül. Valamiért a nyelvek esetén ezt nem hiszi el a legtöbb programozó. Mert ha valakinek X nyelvben rakás befektetése van már, akkor szükségszerűen defenzív lesz vele kapcsolatban.
-
ntomka
nagyúr
válasz
Cathfaern
#115
üzenetére
"nagyon nem arra találták ki, amire (vagy ahogy) jelenleg használják [...] Persze az igaz, hogy a legszarabb nyelvben is lehet jó programot írni, de sokkal jobb, ha már a nyelv is kikényszeríti ezt"
Ezzel viszont nagyon egyetértek.
"És erre azt mondani, hogy akkor a programozókat kell fejleszteni kb. olyan szintű dolog, mint azt mondani, hogy szüntessük meg a warezt"
Pedig de, én ezt látom. PHP-ban és JS-ben is lehet nagyszerű dolgokat alkotni, és alkotnak is. Dolgozok szerencsére olyan emberrel, aki az előbbiből nagyon jó, és szívesen tanulok tőle. Olyan megoldásokat alkalmaz ebben a szerintem is túl laza nyelvben, hogy az életben nem jutna eszembe. Viszont sajnos dolgozok olyanokkal is, hogy az agyam eldobom mikor ránézek a kódjukra. Szóval lehet nem tökéletes nyelvek ezek, sőt, aláírom én is, de hogy lehet velük dolgozni szépen is, az biztos. És aki egy picit is igényes a munkájára, az látja mi a különbség a jól és a rosszul megírt program között, nem pedig csak a működőt és a nem működőt keresi, ami bizony a PHP és JS fejlesztőkre jellemző.
-
Cathfaern
nagyúr
Igazából minőségi hasonlat akart csak lenni, nem tudás/típus alapjáni párhuzam
(illetve nyilván erős túlzás is van benne)ntomka:
Alapvetően az a baj mindkettővel, hogy nagyon nem arra találták ki, amire (vagy ahogy) jelenleg használják (ugyanez a baj mondjuk a html-el is). JS gyakorlatilag egy alpha állapotú valamiből lett szabvánnyá különösebb fejlesztés nélkül, PHP-ba is nagyon sok dolog utólag lett belehegesztve, és bizony ezt megérezni. Persze az igaz, hogy a legszarabb nyelvben is lehet jó programot írni, de sokkal jobb, ha már a nyelv is kikényszeríti ezt... mert a programozók nagy többsége nem jó programozó. (És erre azt mondani, hogy akkor a programozókat kell fejleszteni kb. olyan szintű dolog, mint azt mondani, hogy szüntessük meg a warezt ) -
ddekany
veterán
"Az egy dolog, hogy valakinek nem tetszik egy programnyelv, de ettől még nem lesz rossz."
Nem értem mit nem lehet ezen érteni. Mint mindenből, programnyelvből is van tehetséges és béna emberek által készítettek, szerencsésen és szerencsétlenebbül sikerültek. Ráadásul sok nyelvet nem is nagyon terveznek meg, csak ad-hoc módon nő, ami általában nem vezet jóra (ECMAScript-nek pl. vannak ilyen kilátásai a jövőben rendesen, ahogy rányomnak új paradigmákat). Szóval, de igenis léteznek úgy általában, tervezésükben szarabb meg jobb nyelvek. (Teljesen más kérdés, hogy a jó programozó bármiben tud jót alkotni. Az is más kérdés, hogy egyik nyelv sem jó minden feladatra... Meg még ezer tényezőt sorolhatnánk.)
-
ntomka
nagyúr
Én akármerre járok és akármilyen nyelven írt programot látok, egyelőre jó és rossz programozót látok (esetleg fejlődőképest, mint amibe magamat is sorolnám). Az egy dolog, hogy valakinek nem tetszik egy programnyelv, de ettől még nem lesz rossz. A PHP és a JS is jó és megvan a maga helye és célja, ha jó ember keze alá kerül, mint ahogy minden emberi eszköz.
-
Integra
titán
ezért használnak fizikailag egy második vasat backupnak szinte mindig, amit évente ellenőriznek is. működik a rendszer, nincsen itt baj. a drága meg relatív, igények és cég pénztárca megintcsak. akik mf-et üzemeltetnek nyílvánvalóan megfizetik és jobban megéri mint szopózni gyengébb dolgokkal. higgyétek el, van az a méretű pénzmozgás és tranzakció mennyiség, ahol egyszerűen nem kockáztatnak, mert ha ott lehal a történet, akkor aztán annak a napi kötbéréből egy évig lehet fizetni a teljes mf licenszeket, mert akkora a business impact a szerződésekben foglaltak miatt, szóval egyszerűen nem éri meg.. itt nagyban kell gondolkodni, ez nem kispálya. nem mellesleg ott vannak a tandem gépek is.
azt pedig csöndben jegyzem meg, hogy egy mf fejlesztőnek mindig lesz munkája és most a piac is eljutott odáig, hogy egyre durvábban fizetik őket, sőt, szerintem hamarosan ők lesznek a csúcson gázsiban, ennek is megvannak az okai. mf-fel kurvára lehet keresni..
továbbra is tartom magam ahhoz hogy a sok nyelv teljesen jól megfér egymás mellett, csak nem mindegy, hogy mit mire használnak, milyen környezetben és mik az igények. a cloud tör előre, mert most azt tukmálja az egész ipar, mert pénzt akarnak keresni. a manager meg úgysem ért hozzá alapvetően, ő számokban gondolkodik papíron. tök egyszerű ok-okozat. azt kell elfogadni, hogy nem mindenki rohan a divat után, vannak nagyon jól működő kitaposott és atombiztos irányzatok. -
cadeyrn
aktív tag
@bambano : mainframe vs elosztott rendszerek vitához ajánlom Stanislaw Lem Legyőzhetetlen c. kisregényét, elgondolkodtató.
A mainframe minősége valóban nyomja az x86-ot, ezt nem vitatja senki. Azonban 1 db mainframe sosem fog katasztrófatűrő lenni, nem lesz redundáns és ehhez képest borzasztó drága.
A vaxot jogosan említed, jó rendszer volt, de múlt időben, mert sajnos hagyták kimúlni. Ahogy az alpha processzorokat, a digitalt, és így tovább.
Azonban nem volt minden tökéletes, amit ők csináltak. A VMS pl. elképesztően jól megírt rendszer (még mindig(, de a tökéletessége csak addig ér, amíg nem kell semmilyen külső elem. Csak a saját vasát/programját eszi meg, ellenőrzött forrásból, kézzel válogatva, ami így természetesen döbbenetesen magas szintű, csak éppen ma nem állja meg a helyét, mert muszáj heterogén rendszereket összerakni.A PHP meg nem ördögtől való, vannak sokkal rosszabb dolgok is. Viszont látom a saját kódjaimat X évvel ezelőttről: teljesen minden, C vagy PHP, mindkettő ócska, mert sokkal inkább számít a szemlélet és a tapasztalat, mint az, hogy miben programoz az ember.
A phpmyadmin pont ugyanolyan veszélyes, mint a mysql command line interface-e.
-
#105
ddekany
veterán
fordfairlane
#101
ddekany
veterán
válasz
fordfairlane
#101
üzenetére
Vagy, ideális esetben, valaki aki ért hozzá készít egy nyelvet, aminek ugyan az a célja mint a PHP-nek. Nem így történt sajnos. I.j.
-
-
#103
Integra
titán
fordfairlane
#98
Integra
titán
válasz
fordfairlane
#98
üzenetére
szerintem bambano tökéletesen leírta, ha nem érted, nem érted
mivel mf-fel és mai, általatok "modernnek" mondott rendszerekkel is dolgozunk akad bőven vas a világ minden táján, így nagyjából van némi rálátásom, hogy mi merre meddig megbízhatóságban, stabilitásban, sebességben. mindez globális környezetben, nem 100 fős bilicégről beszélek. összehasonlíthatatlan a két rendszer. ezt minden it-s tudja, egyedül a managerek nem értik, mert nincsen hátterük, na ilyenkor jön a sales bohóc és tukmálja a hulladékot ami az adott igényeknek pont nem felel meg..
az meg, hogy eljárt felettük az idő.. az összes nagy öreg mosolyog az ilyen kijelentéseken, évtizedeken keresztül ezt hallgatták a sok okostónitól, aztán tessék.. térjünk erre vissza majd 10 év múlva. én hallgatok az öregekre, tőlük lehet csak igazán tanulni, én csak mosolygok az ilyen ifjú titáni kijelentéseken
-
#101
fordfairlane
veterán
Cathfaern
#97
fordfairlane
veterán
válasz
Cathfaern
#97
üzenetére
És ez alapvetően a php-nak és a js-nek köszönhető.
A szakma felhígulását nem a php meg a js okozza, hanem a hirtelen megnövekvő igény weblapok-webalkalmazások készítésére. A php csupán eszköz arra, hogy a megnövekedett igényt legalábbis részben ki lehessen elégíteni úgy, hogy lehetővé teszi a gyorstalpaló (ön)képzést. Ha a PHP nincs, akkor nagy valószínűséggel marad a perl, esetleg a vbs (na az még egy gyönyörű nyelv), netán a szerveroldali js-szerűségek.
-
#99
bambano
titán
fordfairlane
#98
bambano
titán
válasz
fordfairlane
#98
üzenetére
nem fogom erőltetni a szövegértést, de ott van fent leírva a technológia, amivel nem duplikálni, hanem háromszorozni is tudták a kiszolgálókat. nyilván ha a leírtakat nem veszi figyelembe valaki, úgy könnyebb leszólni a régi cuccokat.
ja, és az transzparens volt, nem kellett cloud api hozzá. -
#98
fordfairlane
veterán
bambano
#94
fordfairlane
veterán
Semmi olyat nem látok leírva, ami manapság az elosztott rendszerekre ne lenne jellemző. Ami a konkrét technikai megvalósítást illeti, az a kornak megfelelő volt. Mivel nem, vagy csak nehezen tudtak komplett kiszolgálókat duplikálni transzparensen, mert sem a hardver, sem a szoftvertechnológia nem tette lehetővé, ezért mindenféle kereten belüli redundanciát valósítottak meg. Redundáns végrehajtó, memória, adattároló, tápegység stb... Én is úgy látom, akár tetszik akár nem, hogy a mainframe koncepció felett eljárt az idő, így (visszatérve az alapokhoz) a FORTRAN és COBOL felett is.
-
Cathfaern
nagyúr
"Szerintem te nem vagy programozó (nem bántásból, csak a gondolatmeneted erről árulkodik)"
Sajnos nagyon igaza van pedig akár az, akár nem. Tele van az ország (meg a világ) olyanoknak, akik webprogramozóknak hiszik magukat, de valójában webprogramozót alig találni. Ellenben van nagyon sok ember aki tud weblapokat készíteni... és a kettő nagyon nem ugyanaz. Mi cirka fél éve próbálunk embereket keresni, de egyszerűen siralmas a kínálat (igaz részben ez köszönhetően annak is, hogy nem budapesti cég, de a lényegen nem változtat). És ez alapvetően a php-nak és a js-nek köszönhető. -
bambano
titán
"Ez biztos nagy truváj volt a 70-es években, de most már nem az.": mennyire is virtualizáltak a mostani pc-s processzorok? képes hardveres virtualizációt használó rendszer bebootoltatni a virtualizációs réteget egy guesten? ez még a kódmorfingosoknál sem mindig megy, ha jól emlékszem. Kérdés tehát, ha ma már nem akkora truváj a virtualizáció, miért nem tudnak ma olyan szintű virtualizációt az x86-os procik, mint anno az s/370-esek?
"ami elosztott rendszereknél alapvetően nem is nagyon létezik?": így is nézheted, meg úgy is, hogy azért lettek elosztott rendszerek, mert a pc egy hulladék. ha nem lenne a pc megbízhatósága olyan, amilyen (semmilyen), akkor nem kellene cloud, meg nem kellene azon agyalni, hogyan migrálsz egy futó guestet másik hostra, meg ilyenek.
persze érdekelne, hogy a cloudban futó alkalmazásod hogyan éli túl, ha az azt hostoló node pukkan ki. nekem valami azt súgja, hogy sehogy.
"A 6510-es VAX egy 22 éves gép, 62 MHz-es processzorral" szerintem meg 75 MHz-es. De teljesen mindegy, mert hiába 22 éves, ha akkor is többet tudott, mint a mostani pc-k. Hiba lenne feltételezni, hogy a főkeretek azóta nem léptek előre. A főkeretek sem 75MHz-en mennek 128 mega rammal.
Szóval lehet, hogy nosztalgia zóna 22 éves példákat hozni, de ez csak akkor lenne helytelen, ha feltételeznénk, hogy az a szerver-kategória azóta nem fejlődött semmit. De fejlődött, ergo a mostani főkeretek jobbak, mint a 22 évvel ezelőttiek. Ennyi.
"Szerintem te nem vagy programozó"? és itt nagyon erősen a szerinteden van a hangsúly.
-
cucka
addikt
Szerintem senki sem szarozta a mainframe-et, de az érveid többségét a 20 évvel ezelőtti állapotokra alapozod.
- virtualizáció
Ez biztos nagy truváj volt a 70-es években, de most már nem az.- megbízhatóság
Világosíts fel kérlek, hogy egy nagy számítógép hogyan megbízhatóbb, mint egy sok, egymástól elkülönített és redundáns node-ból álló elosztott rendszer?- teljesítmény.
Szerintem ez is megdőlt.hogyan tudott elosztott fájlrendszert csinálni 15 évvel a gfs2 előtt
Az ha jól számolom, 1990-ben volt. Folytassam?vagy hogy lehet vasat cserélni egy vaxban úgy, hogy nem kell üzemszünetet hirdetni? hogy upgradelsz oprendszert futó oprendszeren?
Ismét, 2012 van, mennyire releváns az, hogy egy olyan problémát sikerült megoldani a 80-as években, ami elosztott rendszereknél alapvetően nem is nagyon létezik?Milyen az, amikor robotmechanikás szalagegységre tudsz menteni 1991-ben?
Nosztalgikusde egy ilyen gép ipari hulladék ahhoz képest, ami egy 6510-es vax
A 6510-es VAX egy 22 éves gép, 62 MHz-es processzorral, szóval megint a nosztalgia zónában vagyunk.Izé, nem folytatom, szerintem látszik, mire szeretnék kilyukadni. Senki sem mondta, hogy a mainframe-ek szemétre valók, minden bizonnyal vannak olyan helyek, ahol megéri őket használni, de próbáljunk már kiszakadni a 80-as évekből.
php: ha egy nyelv nem akar szigorú szabályokkal rendre és rendszerességre kényszeríteni, akkor először kiderül, hogy azon a nyelven lehet ócska programokat írni, másodszor kiderül, hogy csak ócska programokat írnak.
Szerintem te nem vagy programozó (nem bántásból, csak a gondolatmeneted erről árulkodik) -
#94
bambano
titán
fordfairlane
#93
bambano
titán
válasz
fordfairlane
#93
üzenetére
hogy ne kelljen az erődet olvasásra fecsérelni, eddig legalább három érv elhangzott tőlem meg Integrától:
- virtualizáció
- megbízhatóság
- teljesítmény.de főleg a megbízhatóság. ezek neked nem szakmai érvek? kezdjem el neked magyarázni, hogy a vax ci interfésze dssi fölött hogyan tudott elosztott fájlrendszert csinálni 15 évvel a gfs2 előtt? vagy hogy lehet vasat cserélni egy vaxban úgy, hogy nem kell üzemszünetet hirdetni? hogy upgradelsz oprendszert futó oprendszeren? nyilván teljes migrációval, ezt már nem is említem.
Milyen az, amikor robotmechanikás szalagegységre tudsz menteni 1991-ben? Vagy remote bootolni tud cd szerverről egy gép? Vagy hálózattranszparens grafikus felület van az oprendszerben már akkor, amikor a windows 3.1 éppen csak megjelent az usákoknál?
ha neked magyarázni kell, hogy miért jobb a főkeret, akkor valójában nem is kell magyarázni. c:\dos\command.com... rotfl. architekturálisan a legutolsó ótvaros r55 is jobb volt 1990-ben, mint a mostani pc-k. úgy értem, vagy 50 évvel.
tudsz pl. mikrokódot cserélni egy pc-s processzorban úgy, hogy közben futnak rajta az oprendszerek? van egy pc-ben alternatív út a diszkekhez? vagy legalább egy rendes tápegység? vagy olyan szervizprocesszor, amelyik fenntartja a szolgáltatást addig, amíg a főprocit kivette a szerelő? természetesen szolgáltatáskiesés nélkül.
-
#93
fordfairlane
veterán
bambano
#92
fordfairlane
veterán
de egy ilyen gép ipari hulladék ahhoz képest, ami egy 6510-es vax (ami még mindig nem főkeret, max. midrange), vagy egy 4361-hez képest, ami igazi főkeret volt a maga idejében.
Mi ez a nagy mainframe fétis? Eddig még nem sok szakmai érv hangzott el ezzel kapcsolatban, csak a szokásos lenéző fölényeskedés, ami pont nem a hozzáértést igazolja.
-
bambano
titán
nekem pl. egy eserver x3650 nem dzsunkapc, még talán azt is mondhatnám, hogy nekem egy ilyen gép (a maga *méret*kategóriájában) a pc-k csúcsa.
de egy ilyen gép ipari hulladék ahhoz képest, ami egy 6510-es vax (ami még mindig nem főkeret, max. midrange), vagy egy 4361-hez képest, ami igazi főkeret volt a maga idejében. pl. hol vannak a pc-k virtualizáció tekintetében egy igazi főkerethez képest? kb. ott, ahol a 60-as években a főkeretek tartottak. van még ötven év hátrányuk.
a cloudról alkotott véleményem ismert, viszont azt gondolom, hogy minél nagyobb pénzeket fognak bevasalni a cloudra átállást elkapkodók egy leállás után, annál inkább főkeretre fognak költözni azok a cloudok, amelyek gazdái valamit is komolyan gondoltak.
Majd vesznek pár főkeretet, mindegyiken el fog futni 10-20 ezer darab pc-nek megfelelő mennyiségű cloud kliens és kész. vagy marad a kevéskilences rendelkezésre állás.a szélszes nem vásárol eszközt, hanem elad. jelen esetben tukmál.
php: ha egy nyelv nem akar szigorú szabályokkal rendre és rendszerességre kényszeríteni, akkor először kiderül, hogy azon a nyelven lehet ócska programokat írni, másodszor kiderül, hogy csak ócska programokat írnak.
-
cucka
addikt
Hagyjuk már a kesergést, a többi nyelvnek pont ugyanúgy megvannak a saját bajai. Például a php legnagyobb baja, hogy elnézően kezeli a rossz minőségű kódot, az egy elég hiteltelen érv egy olyan iparágnál, ahol a Perl első számú szkriptnyelv lehetett.
Most érted, attól, mert a php-ban a függvények paraméterezése néha logikátlan vagy hogy lehet benne szarul is programozni, még nem fog összedőlni semmi, ez csak egy gumicsont. Minden nyelvben találsz logikátlanságot és minden nyelvben lehet szarul programozni. Az összes, php ellen felhozott hasonló érv vagy pusztán esztétikai kifogás, vagy pedig olyan, ami hozzáértő fejlesztő esetén nem releváns.
(#89) bambano
az egyik ok, hogy azt a megbízhatóságot, amire egy banknak szüksége van, a mai pc-k még mindig nem tudják.
Attól, mert egy rendszer elosztott, még nem feltétlenül dzsunka pc-kből épül fel. (Vagy a pc alatt általában az x86-os architektúrákat érted?)a másik ok pedig az, hogy pénzt akkor lehet kizsarolni az ügyfélből
Egy dolog, hogy mik jelenleg az informatikai trendek, hova fejlődnek az elosztott rendszerek. Az más kérdés, hogy a témához amúgy nem értő pénzügyesek meg sales-esek meg hasonló emberek milyen módon vásárolnak eszközöket cégek számára. Az első egy érdekes kérdés, a második pedig egy irreleváns kérdés.azok a programok, amik mostanában veszélyeztetik egy rendszer integritását, valahogy mindig úgy kezdődnek, hogy php... és a végződésben van pl. olyan, hogy myadmin.
És ez a tapasztalatod milyen tanulságokkal szolgál magáról a php nyelvről? -
bambano
titán
az egyik ok, hogy azt a megbízhatóságot, amire egy banknak szüksége van, a mai pc-k még mindig nem tudják. a pc az még mindig a bohócliga, más kérdés, hogy sok helyre elég.
a másik ok pedig az, hogy pénzt akkor lehet kizsarolni az ügyfélből, ha változtatást tukmálsz rá. azért soha nem fog fizetni, hogy van egy főkerete, te meg, mint sales manager special főfőaccount kezelő, beállítasz a főnökhöz, hogy milyen jó is a főkeret. Pénzt akkor tudsz kivasalni belőle, ha főkerete van és rábeszéled a cloudra, hogy az milyen jó. beruház, megveszi, majd hagyod pár évig főni a levében, és utána elkezded neki magyarázni, hogy nem cloud, hanem főkeret.
ezt csinálják évtizedek óta.
-
bambano
titán
azok a programok, amik mostanában veszélyeztetik egy rendszer integritását, valahogy mindig úgy kezdődnek, hogy php... és a végződésben van pl. olyan, hogy myadmin.
és az egy dolog, hogy lehet benne rendesen programozni, de a másik dolog az, hogy rendetlenül lehet-e? mert jó nyelvben nem annyira.
-
#87
bambano
titán
fordfairlane
#74
bambano
titán
válasz
fordfairlane
#74
üzenetére
az milyen? 3270-es emuláció? meg xedit?
mert azok igen jól használható cuccok.
as400-on nem dolgoztam még, de azok elég messze vannak a főkeretektől.
főkeret kategória, ami focizik, olyan, mint mosógép. bemegy a hideg víz és kijön a meleg.
amit 1-2 ember fel bír emelni, az nem főkeret, csak valami koszolás. -
cadeyrn
aktív tag
Tudom, hogy flame, de...
... mondjátok már meg, PHP-t fikázók, mi tart vissza attól, hogy megfelelő módon használjátok a PHP-t? Nem hiszem, hogy a brainfuckon és a LOLCODE-on kívül van olyan nyelv, amiben nem lehetne jól, struktúráltan és értelmesen programozni, csak ember, tudás, lehetőség, idő és optimalizáció kérdése -
ddekany
veterán
Ja, hát ez lényegében a fókusz hiánya az adott területre (weboldal készítés)... Nagy kár, hogy anno senki hozzáértő nem fedezte fel ezt a rést, pontosabban, hogy milyen szögből kell támadni (könnyű kezdés, kulcsrakészség). Ha lenne afféle romantikus szakmai böcsület és büszkeség, én mint szoftveres szégyellném magamat, hogy ez így történt ahogy. Amúgy ezért is tartom rombolónak az egész jelenséget, aminek simán a szimbóluma lehetne a PHP... Mert az egy dolog, hogy gyakorlatilag egy-két ember fiatalos ostobasága miatt kell szükségtelenül többet vacakolni millióknak. De még ott van az is, hogy mennyire demoralizáló ez azoknak, aki esetleg amolyan gyermeteg módon valóban szeretik és értik is szakmájukat. Oh well...
-
ArchElf
addikt
Kettős a dolog kis rendszereknél (még nagy cégeknél is) tényleg erősen nyomul a virtualizáció.
Viszont az üzleti core rendszereket egyszerűen nem éri meg kidobni. Soha nem termli ki a cég az a több 100 milliós (vagy milliárdos) nagyságrendű költséget, amibe csak a csere alapból kerül (és akkor még a régi rendszerhez illesztett szatelitekről nem is beszéltünk).Integra: Indiai support - na erről tudnék mesélni
AE
-
Integra
titán
egy hülye százat csinál, agyrém komolyan.. szerintem jópáran cumiztunk már indiai supporttal..
sajnos a kis büdzséből gazdálkodó cégek a verseny miatt bevállalták, meg menedzsmentnek is prezentálni kell a számokat a nagyobb prémiumokért, aztán jól belefutottak egy ördögi körbe, mert már az elején hazudtak saját maguknak.. közben meg rohadt a support és a munka sem ment úgy, ahogy régen.. és mennyi ilyen van..
el lehetett adni az egészet és a cégek be is vették. ideig óriág megy is, aztán úgyis borul a bili. van aki erre rájön és mert változtatni, és van aki már csak dafkéból sem és amig nem omlik össze a biznisz, addig megy. aztán ha összeomlott akkor majd vakargatják a fejüket és akkor talán lépnek. ahány cég annyi vezetés és döntés.
szerintem katasztrófa az indiai support. és aki indiából koponya, az már rég usa-ban vagy ny-eu-ban van és domesztikálódott, ki tudja, talán már kezet is mosnak rendesen... -
#80
fordfairlane
veterán
floatr
#79
fordfairlane
veterán
Erről az outsourcingról mindig ez a videó ugrik be:
-
Integra
titán
cloud és mf technológia teljesen más és teljesen más céllal működik, nem is ugyanaz a két cégcsoport. akinek az adatai életbevágóan fontosak, azok nem fogják kiadni az adatparkjaikat, megépitik inkább a sajátjukat. teljesen jól megfér a kettő egymás mellett. az adatvédelem miatt az igazán komoly cégek nem fognak cloudozni. van pénzük rá, hogy megtehessék, hogy ne tegyék, sokkal többet érnek azok az adatok, mint az a szaros szerverpark valaha érni fog. cloudot alapvetően a kisebbek használják, akiknek nem éri meg a saját. és van ebben valami, nem feltétlen rossz ez, csak megint azt mondom, nem ugyanaz a célcsoport, nem ugyanazok a célok és okok, indokok.
ha pedig az mf kifutó lenne, akkor az ibm sem fejlesztené mai napig és a vállalatok sem használnák mai napig illetve fejlesztés sem menne rá. pedig van, max nem látod mert nagyon más téren mozogsz, semmi baj nincsen ezzel. miért fejleszti? mert van rá igény és lesz is rá még nagyon sokáig. szerintem az ibm nem hülye.. ahogy a nagyvállalatok is amelyek ezt a technikát használják. nem lehet, hogy megvan az okuk rá, amiről te nem tudsz, vagy nem akarod megérteni?
nyilvánvalóan egy apple és egy google más cégprofil mint bankok és hatalmas állami és magán vállalatok, amik nem tech cégek, de a működésükhoz elengedhetetlen a support részleg is. azért mert mit csinál a google ez absz semmit sem jelent arra nézve, hogy teljesen más profilú vállalatok mit csinálnak és forditva
ez a cloud tisztára olyan mint az outsorcing, boldog boldogtalan kiszervezte a supportot indiába, mer az jó, mer az olcsó.. az igazán okosak meg sosem tették, megbecsülik a saját belső munkaerőt. be is jött nekik.
azt meg már csak csöndben jegyzem meg hogy megy a gameframe fejlesztés is, asszem a neve mindent elmond
-
cucka
addikt
járjál utána az mf-nek egy picit, mert úgy látom, sok rálátásod nincsen.
Annyi rálátásom azért van, hogy észrevegyem, az összes meghatározó szereplő elosztott rendszerekben gondolkozik, cloud-ba pakolja az infrastruktúráját, stb.
Az, hogy néhány banknál meg gigacégnél vannak mainframe-ek, sokmindent jelent, de ezt a nyilvánvaló trendet nem cáfolja. Komolyan, ez olyan, mint ha jönnél azzal, hogy a vízesésmodell egy remek fejlesztési paradigma, mert pár becsontosodott nagycégnél még használják. A téma, hogy a technológia merre tart, nem pedig az, hogy hol volt 20 éve, még akkor is, ha sok helyen működnek a mai napig 20 éves rendszerek.Nem köpködöm a mainframe-et, pusztán annyi az állítás, hogy eljárt fölötte az idő. (És nem csak a mainframe, mint vas alatt, hanem az egész elképzelés alatt). Meg lehet nézni, mit csinál a Google, az Amazon, az Apple, vagy bármelyik nagy technológiai cég,
-
cucka
addikt
Python alatt egy Pylons nevű framework-el vannak tapasztalataim (jelenleg is ebben fejlesztek). A tetszetős rész az a Python, mint nyelv, a kevésbé tetszetős részek:
- A Python nyelvet alapvetően nem weboldalak gyors legyártására tervezték. A php rengeteg kényelmi szolgáltatással jön alapból, ezek többségét itt külső libekkel lehet megoldani, amelyek vagy jók, vagy nem
- A futtatókörnyezet kialakítása nehézkes. Elvileg van szabványos módja annak, hogy egy Pylons app letöltse és bekonfigolja magának a szükséges libeket, sajnos a gyakorlatban ez nem működik
- Véleményem szerint a Python doksija nem a legjobb, a Pylons-é meg egyenesen fostalicska. Ebben a tekintetben a php-nál nagyon magasan van a léc
- A hostolás nálunk nem téma (dedikált virtuális gépek cloud-ban meg minden ), de ha a hobbiprojektedhez szeretnél hosting szolgáltatót, akkor elég kevés a lehetőség. -
#74
fordfairlane
veterán
fordfairlane
#72
fordfairlane
veterán
válasz
fordfairlane
#72
üzenetére
És BTW aki pedig az AS/400 konzolját, a programszerkesztőt, meg a hozzákapcsolódó billentyűkombinációkat kitalálta, azt legszívesebben végigkergetném a nagykörúton. Ezt a szart egyszerűen nem lehet megszokni. Bocs, vége az OFF-nak.
-
#72
fordfairlane
veterán
Integra
#64
fordfairlane
veterán
nem azért használnak globális nagyvállalatok, bankok, olajcégek etc mainframe-t mert az régi és ha már az van, akkor használjuk tovább,
Hát, pedig de, döntő többségben ez szól amellett, hogy ezeket az őskövület platformokat használják, meg hogy csillió dollárba kerülő fejlesztőket fizessenek meg ezen rendszerek fejlesztésével/karbantartásával. Épp most szembesülök egy banki IT rendszerrel, heterogén trágyadomb az egész, de többé kevésbé működik, így még mindig olcsóbb fenntartani, karbantartani, görgetni a dolgot, mint kukázni az egészet, és mindent újraírni.
-
cucka
addikt
Tényleg csak példának, mondjuk Python vagy akár Ruby nyelven. Nyilván költői a kérdés, mert ezekben rövidebb és esetleg megbízhatóbb is lesz a cucc...
Rubyval nincs tapasztalatom, Python-al igen. Ha a fő szempont a pöcsölés-mentesség, akkor én a php-t választanám, bár tény, a Python egy sokkal jobban átgondolt nyelv.Mellékesen az is félig legenda, hogy statikus nyelvekben hosszabbak a programok.
A program hossza szerintem az absztrakciós szinttől és az elérhető lib-ek és eszközök minőségétől függ, bár szerintem a program hossza (vagyis praktikusan a kódsorok száma) egy eléggé semmitmondó metrika. -
Integra
titán
nem fogytam ki, csak reagáltam a bullshitezésedre, nem tetszik? ne bullshitezzél, mert az amit irsz.
az az ő bajuk, szivnak is a rendszerekkel. járjál utána az mf-nek egy picit, mert úgy látom, sok rálátásod nincsen. a mainframe él és élni fog, akkor is, mikor ezek az alnternativ megoldások már rég halottak és valami újat próbálnak eladni helyettük. hányszor temették már az mf-et, aztán mégis itt van él és virul és keményen megy a fejlesztés rá. csak kevesen engedhetik meg maguknak, ennyi. nem kell leköpni azt ami öreg, hiába divat a fika
nem nekem kell hinni, hanem a történelemnek, az pedig tökéletesen bizonyitja, hogy ezeknek a rendszereknek igenis van létjogosultságuk és még sokáig lesz is, nem is kicsi. max nem kicsiny magyarhoni piacban kell gondolkodni.. -
cucka
addikt
nem azért használnak globális nagyvállalatok, bankok, olajcégek etc mainframe-t mert az régi és ha már az van, akkor használjuk tovább, mert nem éri meg, hanem mert geci drága és sokan inkább próbálják kiváltani olcsóbb rendszerrel, amiről tudják, hogy hulladék és nem hozza azt amit az mf tud, de legalább a managerek prezentálhatják a költségcsökkentés számát
Ki kell ábrándítsalak, a bankszektort és néhány nagy céget leszámítva senki sem mainframe alapon képzeli el nagy mennyiségű adat tárolását, kiszolgálását. Egyáltalán, a jelen szempontjából teljesen irreleváns olyan cégekkel példálózni, ahol teljesen mindennapos dolog, ha a 80-as, 90-es évekből ittmaradt szoftvereket, rendszereket használnak.
A jelen az elosztott rendszerekről szól - klaszter, cloud. Az összes nagy szolgáltató ilyen rendszerekben gondolkozik, lásd Google vagy Amazon, vagy lényegében bárki más..újrairni? újra lehet, optimalizálva, okosabban, modulárisan megirni a kódot, lehet, persze. csak még jobb lesz. ez igy működik, igy lett kitalálva, igy stabil.
Világos, csak akkor megint ott vagyunk, hogy a mainframe-en több évtizede üzemelő fortran/cobol alapú ökoszisztémák létezése mellett az egyetlen érv, hogy üzletileg nem éri meg őket lecserélni.inkább te általánositasz, én meg konkrétan látom a különbséget, hogy az adott hardver és szoftver hogy működik együtt és mit tud egy másik adott hardver és szoftver pároshoz képest.
Abszolut meggyőzhető vagyok, csak mondj már 1-2 konkrét példát erre..ilyenkor jönnek az olyan alternativ (és borzalmas) megoldások mint a sap.. ami amúgy sok esetben szintén mf db2 táblákból dolgozik, nem véletlenül
Ööö, most akkor te egy rendszermérnök-szerűség vagy, akinek komoly tapasztalata van nagyon magasra skálázódó architektúrák terén (az itt előadott arcod alapján igen), vagy egy pénzügyes-manager-akármi, akinek a mindennapi rutin része az SAP-val történő szívás? Vágod, az architektúra az egy dolog, a rajta futó alkalmazás (ez lenne az SAP) meg egy másik dolog.de mondhatnám azt is, hogy szerintem meg a te irásod jellegzetes bullshit-szöveg, fiatal világ kódere duma, aki a nagy öregeknél is jobban tudja mi fán terem a világ, de még a tojás héjj is ott a seggén..
Kifogytál az érvekből, most jön a látatlanban vagdalkozás a személyem ellen? -
Integra
titán
találkoztam olyannal is már, mikor pár valóban ügyes és tehetséges kóder a létező rendszerekben használt kód újra/átirásával optimalizált volna a process időket és az első tesztek után leállitották őket, mert túl eredményesek voltak.. miért? mert a kis managerek nem tudták volna eladni a felső vezetésnek, hogy de mindenképpen új hardver kell, mert a mostani már nem birja....
-
ddekany
veterán
Hogyne. Mint ahogy bármilyen fostalicskában, ami Turing-komplett lehet csodálatosakat alkotni... Én azonban egy ilyen deviáns alak vagyok
, és szerintem akkor már jobb nem-fostalicska nyelven szépet alkotni. Mert hát sok okos ember van, aki tud olyanokat is csinálni ám. De nem, vérpista szarját kell használni, mert... őőő... -
-
ddekany
veterán
"Végül is a PHP csont nélkül teljesíti a hozzászólásodban leírt fő feltételt - gyorsan és pöcsölés nélkül lehet benne megoldani a dolgokat."
Mennyiben kell több "pöcsölés" akkor, ha az ember egy nem inkompetens emberek által összegányolt de hasonlóan "script" nyelven ír meg valamit? Tényleg csak példának, mondjuk Python vagy akár Ruby nyelven. Nyilván költői a kérdés, mert ezekben rövidebb és esetleg megbízhatóbb is lesz a cucc...
Mellékesen az is félig legenda, hogy statikus nyelvekben hosszabbak a programok. Valamennyivel nyilván, a mindenféle deklarációk miatt. Azon felül ez inkább kultúra kérdése... A dinamikus nyelvekben a tervezők általában igyekeznek tömören kifejezni dolgokat, meg elég hamar felkapják az új paradigmákat, míg a populáris statikus nyelvek általában szarnak ezekre. Most csak példának, Java-ban a mai napig nincs semmi, amivel JavaBean property-ket lehetne gyorsan definiálni egy osztályban, és erre nincs is kilátás. Nem normálisak. Project lombok mondjuk egy próbálkozás erre, de hát amíg nem része a nyelvnek...
-
Integra
titán
kiigazitanálak.
azért nézd meg mit kér az ibm a mainframe licenszekért.. meg fogsz lepődni..
nem azért használnak globális nagyvállalatok, bankok, olajcégek etc mainframe-t mert az régi és ha már az van, akkor használjuk tovább, mert nem éri meg, hanem mert geci drága és sokan inkább próbálják kiváltani olcsóbb rendszerrel, amiről tudják, hogy hulladék és nem hozza azt amit az mf tud, de legalább a managerek prezentálhatják a költségcsökkentés számát (a support meg cumizhat..), hanem azért mert ez az egyetlen rendszer ami képes mai napig azt az adatmennyiséget stabilan és nagyon gyorsan feldolgozni, miközben nem lehet feltörni sem.
újrairni? újra lehet, optimalizálva, okosabban, modulárisan megirni a kódot, lehet, persze. csak még jobb lesz. ez igy működik, igy lett kitalálva, igy stabil. az kéne még, hogy belepiszkitsanak sallangokkal, onnantól lenne igazán csodás ekkora rendszereket karbantartani és megfelelő sebességgel üzemeltetni
szóval hagyjuk ezt a jellegzetes bullshit dumát inkább.. inkább te általánositasz, én meg konkrétan látom a különbséget, hogy az adott hardver és szoftver hogy működik együtt és mit tud egy másik adott hardver és szoftver pároshoz képest. ég és föld. de mindegy, nem magyarázom, felesleges, hiszen ez csak bullshit
ha tehetné, minden nagy cég mf-et állitana csatasorba, csak nem tudják megfizetni.. ilyenkor jönnek az olyan alternativ (és borzalmas) megoldások mint a sap.. ami amúgy sok esetben szintén mf db2 táblákból dolgozik, nem véletlenül
de mondhatnám azt is, hogy szerintem meg a te irásod jellegzetes bullshit-szöveg, fiatal világ kódere duma, aki a nagy öregeknél is jobban tudja mi fán terem a világ, de még a tojás héjj is ott a seggén..
szóval hagjyuk inkább.. -
cucka
addikt
A PHP-t meg bár ne említetted volna... Remek bizonyíték arra, hogy mennyire nem az dönti el egy nyelv sikerességét, hogy milyen jó vagy szar egy nyelv.
Végül is a PHP csont nélkül teljesíti a hozzászólásodban leírt fő feltételt - gyorsan és pöcsölés nélkül lehet benne megoldani a dolgokat. Persze, ettől még elég csúf nyelv(#58) Integra
vannak dolgok amiket a mai modern nyelves rendszerekkel egyszerűen nem lehet megoldani. nincsen mögöttük sem stabilitás, sem megfelelő számolási képesség, teherbirás.
Szerintem ez ilyen jellegzetes bullshit-szöveg. A Fortran meg a Cobol nem azért használatos még mindig, mert olyan f*sza nyelvek lennének, hanem mert vannak létező rendszerek, amelyek ilyen nyelvekben készültek és nem éri meg újraírni őket. Nagy cégeknél, bankoknál simán előfordulhat, hogy ősrégi szoftverekkel működik az infrastruktúrájuk, de ebből azért nem érdemes semmilyen általános érvényű következtetést levonni. -
ddekany
veterán
Mert a "mai modern nyelvek" általában nem vasközeli/system programmingra fókuszálnak... Mi több azt figyelmen kívül hagyják. Miért? Mert úgy sincs senkinek esélye a C ellen, minek után az már mindenbe mélyen beleette magát, ide értve egyes programozók agyát is. Ha csak kicsit is magasabb szintet akar valamit, akkor ott a C++ terpeszkedik a maga borzalmaival, szóval ott sincs már hely megújulásra. Eggyel feljebb, a VM-es (vagy akár csak GC-s?) világban ott a Java, a maga kőagyú (C-s) ostobaságival. Meg a C#, az viszont gonogszmájkroszoft. Helyek betöltve. A dinamikus/script szférában még nem született meg az örökös darab... Ott messze a legszarabb nyelv a PHP, de ennek ellenére nem hiszem hogy átveszi a világhatalmat, kivéve talán kisvállalati Weboldal pöcögtetés terén. De nagy esélyeket adok a ECMAScript későbbi leszármazottjainak a a "script" téren. Majd ragasztanak rá opcionális erősen típusosságot meg osztályokat. (Ruby esélytelen, mert túl kerek. Smalltalk sors...)
-
#61
bambano
titán
fordfairlane
#60
bambano
titán
válasz
fordfairlane
#60
üzenetére
ha megnézed úgy alaposabban a fortrant, kiderül, hogy az s/360-as assembly utasításokkal annyira szorosan rokon, hogy majdnem egy-az egyben fordítható. Akár fejben is.
Különben is a rendszerterületek negatív tömbindexekkel való módosítása nem hátulgombolósoknak való feladat -
#60
fordfairlane
veterán
cadeyrn
#51
fordfairlane
veterán
Az igazi programozó kérlek szépen úgy programozik, mint anno c64-en. Tudja a karakterek kódját, és hogy ez gépi kódban melyik utasításnak felel meg, tehát közvetlenül a képernyőkarakterekkel írja be a processzor utasításait. Semmi flanc, semmi memória monitor program, amelyik a mnemonikokat binárisba átrakja, pláne nem assembler! A FORTRAN meg a COBOL az elkényelmesedett programozó punciknak való!
-
ddekany
veterán
"Se a FORTRAN, se a COBOL nem elavult, csak sokkal jobban kell hozzá érteni"
Egyikhez sem értek, de... a nyelvek egyik lényege, hogy ugyan adott problémát minél kevesebb pöcsöléssel oldjál meg. Azaz, az, hogy jobban kell hozzá érteni, általában nem "csak" dolog, hanem gond a nyelvel. (Most attól tekintsünk el, amikor maximálisan kímélni kell a vasat, és azért olyan valami amilyen. Nem az a jellemmező.)
"mégis az a véleményem, hogy a legmagasabb szintű hatékony nyelv a C"
Hát azért... C... Van rá sok értett fordító, pirítós sütőre is, stb, de azért mégis. A minimalizmusnak is meg van a határa. Pl. hogy valami egységes és lehetőleg strukturált-szerű (értsd, ami nem zabál erőforrást ahhoz képest, mint ha én írom oda, hogy if(fail) {seterrnotakármi(); goto takarítás / return fail;}) hibakezelést sincs benne, az azért már mindennek a teteje. Meg van mindenki húzatva ebben a szakmában is.
A PHP-t meg bár ne említetted volna... Remek bizonyíték arra, hogy mennyire nem az dönti el egy nyelv sikerességét, hogy milyen jó vagy szar egy nyelv. Jókor, jó helyen, jó hátszéllel... annyi.
-
Integra
titán
haha, jaja, hány évtizede temetik a cobol-t, aztán tessék... az egyik legbombabiztosabb, legtisztább nyelv, nem véletlen létezik a mai napig mainframe.. és létezni fog, mikor már a jóisten tudja hányadik bőrt húzzák le a mai "modern" nyelvekről..
csak már kinek mond bármit is a mainframe? a legkevesebbeknek. ránéznek egy mf képernyőre és lefagy a script a fejükben azonnal, hogy wtf.. -
-
ddekany
veterán
-
bambano
titán
A tudományos programok jelentős része, kapaszkodj, FORTRANban van. És még mindig használják, mert nincs értelme újraírni.
A bankvilágban pedig a COBOL a menő. A cobolból 1972-es az a szabvány, ami anno nálunk nagyon elterjedt, a fortranból meg 1977-es.Senki nem fizeti meg, hogy újraírjanak párszázezer soros programokat, ha egyébként működnek.
-
ddekany
veterán
"Ezen már régóta vitatkozik a sok fejlesztő, hogy mi a gány (szvsz a c++ makró is az), de sosem lesz világbéke ebben a témában sem."
Mert ugye az átlagprogramozó sem különb más átlagembereknél, és afféle vallási klikkekbe tömörül. És ha pár sárgalacsin már arcon talált a túloldalról, akkor nincs visszaút, és ömlik mind a két oldalról a butaság. Pedig valószínűleg az ideális megoldás legtöbb feladatra az lenne, ha mind a kettő megközelítést támogatja a nyelv, és ahol nincs útban ott statikus típusosságot használsz, mert hát ez Neked (is) segít, máshol meg dinamikusat. A Fantom állítólag valami ilyet csinál amúgy (nem ástam bele soha).
Szegény Java meg... valaki visszamehetne az időben és éjjel Vulkán bolygó lakónak álcázva megfenyegethetné a tervezőit, hogy ha nem raknak bele rendes típusparamétereket, és ha elcseszik a null kezelést C-módra, akkor kiolvasztjuk az agyukat. Ha valaki visszamenne, szóljon, mert még van pár apróság... pl. a C-féle kasztolás is, unió típusok helyett. Ezekkel teljesednek ki az ellenőrzés, de ezek helyett félmegoldás lett a vége.
-
julius666
addikt
Valószínűleg amúgy azért lett ez ilyen, mert a rendes típusosság JS-re fordítva problémás lett volna, azt meg nem merték meglépni hogy ne lehessen bármilyen böngészőben Dart kódot futtatni. Nem hiszem hogy az egyébként tervezésbeli cél lett volna hogy éles futás közben ne legyen típusos a nyelv csak debugnál.
Én gány alatt azt értettem hogy úgy tesz a nyelv mintha mégiscsak erősen típusos lenne. Értem én hogy ez debughoz jó mert pár hiba futási idejű helyett fordítási idejű lesz de ilyen típus-utalásokat belerakhatok JS-be is kommentként amire aztán lehetne ellenőrizni, nem kéne külön nyelvi elemként bevezetni őket. Ez így csak egy kiváló megtévesztés a nyelvvel ismerkedők számára ami aztán problémákhoz vezethet.
-
floatr
veterán
válasz
julius666
#43
üzenetére
Én meg úgy gondolom, hogy ha valakik, akkor ők igazán megtettek mindent annak érdekében, hogy a lehető legjobban optimalizálják a JIT működését, és ha ezt a megoldást VM/JIT barátnak mondják, az a minimum h ezt fenntartás nélkül elhiszem.
Más kérdés, hogy ki mit tekint gánynak. Én pl az erősen típusosnak mondott java-ban a generics és tsai megoldását tartom annak, amihez képest ez a szintaxis öröm és boldogság. Ezen már régóta vitatkozik a sok fejlesztő, hogy mi a gány (szvsz a c++ makró is az), de sosem lesz világbéke ebben a témában sem.
-
julius666
addikt
ha az ie böngijében elfért még egy nyelv (VBS), akkor a gugliéban is elfér a dart
Elférni elfér, csak felesleges várni tőle bármit is.
Egyébként nekem továbbra sem azzal van bajom hogy valaki le akarja váltani valami jobbal a JS-t, hanem hogy ez a Dart cucc nem igazán jobb szvsz. Ez a "megpróbálok úgy tenni mintha erősen típusos lennék pedig nem vagyok az" dolog pl. kifejezetten unszimpatikus, ez így gány. -
#42
Winner_hun
félisten
Winner_hun
félisten
hogy a képes legyen
Az "a" után lemaradt a "z"
-
floatr
veterán
válasz
julius666
#40
üzenetére
Ezt eddig objektum-alapúként ismertem, mivel az OOP alapelvei közül elég sokat nem teljesít ahhoz, hogy akként lehessen emlegetni. De nem veszünk össze a definíción, a lényeg h már vagy 5 éve lehetnének komolyabb struktúrák a JS-ben, ha a ms nem a SL preferenciája miatt véli túl veszélyesnek a biznicére a fejlesztések irányát. Mire meg a JS.next beérik, addigra már a dart is elterjed, vagy bármi más, ennyit a ES munkacsoportok munkájáról.
Egyébként ha van felesleges időd, meg lehet nézni az ES4/next tervezetet. Nem gányolás.
BTW: ha az ie böngijében elfért még egy nyelv (VBS), akkor a gugliéban is elfér a dart.
-
julius666
addikt
Eich már rég elvitte volna OO irányba az egészet
Őőő... A JS OO nyelv, csak prototípus-alapú az öröklődés, nincsenek osztályok. Ami szvsz a dinamikus, gyengén típusos környezethez jobban is illik. Vagy gyúrják újra az egészet vagy maradjon ez, de szerintem hatalmas hiba lenne össze-vissza belegyúrni különböző paradigmákat csak azért mert sokan lusták megérteni az alapkoncepciót/nem tetszik nekik. Így is van benne pár gány megoldás, nem kell több.
Az ES5 nyilvánvalóan nem a nyelv újragondolása volt hanem csiszolása, pár hiányosság bepótolása és pár hiba kigyomlálása (lásd strict mode).
#35 FTeR:
Tudom, erről beszéltem, leírtad kb. azt mint amit én még egyszer csak máshogyan. -
floatr
veterán
Egyébként ne magyarázd bele a mondandómba h a nyílt szabványok ellen beszélek. Amiről beszéltem, az az ES4-es munkacsoport ellehetetlenítése, amikor a microhoo egymásnak vetett háttal állta el az utat, és hiába akarta mindenki más, hogy haladjon is az egész eladták az ES3.1-et meg az ES5-öt hűdenagy innovációnak, miközben az Adobe már 10 évvel ezelőtt is előrébb járt, mint ezek ketten. Gondolom ez a zsákutca állapot szülte meg a gugli taktikáját, hogy akkor majd csak megszerettetik a néppel, ha már a microhoo a szabvány fejlesztését ennyire ellehetetleníti.
Személy szerint meg azt tudom mondani, hogy mi miatt kéne ágálni ellene? Technológiai szempontból akár evolúciós lépésnek is beillik, és ésszerű is. Nem kötődik érdemben senkihez sem, mert senkinek nem érdeke, hogy korlátozza. A guglinak viszont érdeke,hogy minél gyorsabban terjedjen, mivel a web bárminemű fejlődése nekik kedvez -- ezért pénzelik a projektet -- és most mindenki sóhajtozik, hogy "majd biztos ezzel lopja el az adatainkat"
-
ddekany
veterán
"A C++ nem egeszen jo pelda, a mai napig eleg sok zoldmezos C++ projekt indul."
Pont ezért jó példa. Ősrégi darab, és persze ennyi idő alatt már okosabbak lettünk és jobbat tudnák alkotni ugyan arra a területre. De szinte senki neki sem áll, mert annyira esélytelen kiváltani egy ennyire bejáratódott eszközt. Én simán el tudom képzelni, hogy a kezdeti sok forrongás után, lassan kilépünk az informatika gyerekkorából, és ami akkor megmaradt... Mint ezeregy dolog ami megcsontosodott a civilizációban, és már soha nem tudod megreformálni (a QWERTY billentyűzet kiosztás, az írásunk, és persze a praktikátlan emberi nyelvek, mint az Angol meg a többi... valószínűleg örök darabok most már).
-
floatr
veterán
Az eredeti megoldás sem az ECMA keretei között készült FYI. Nem az történt ugyanis, hogy összeült pár mammutcég képviselője, és kiadtak egy függetlenségi nyilatkozatot a specification request-tel. Eich otthon szépen megszakértett valamit, öteletelt, aztán a netscape akkori középvezetőit meggyőzte, és léptek egy nagyot. Majd később azt gondolták, hogy ebből mindenki profitálhat, és szabványosították. De ezek a dolgok nagyjából mindig így történnek, jó példa erre a java, ahol ugyan nem szabványokkal dobálóznak, de a JCP központosítja a specifikációkat, amiket korábban iparági szereplők már rég piacra futtattak.
-
FTeR
addikt
válasz
julius666
#10
üzenetére
nem a js-sel van gond és még csak nem is implementációkkal (habár azzal vannak rendesen bajok*), hanem a DOM API-val. A jQuery azért tarol, mert a DOM API-t elrejti egy CSS jellegű megoldással.
*kezdve azzal, h gyak egy alpha verzió került a netscape-be, ami a natscape-el együtt el is tűnt volna a történelem süllyesztőjében, ha ms nem menti át ie-be. A nyűg abból ered, hogy túl jól sikerült az átmentés, a bugok is 100%-ra implementálva lettek.
-
-
floatr
veterán
Az szvsz sokkal fontosabb lenne, ha JS kód is futhatna Dart VM-ben.
Mellesleg kinek kéne tolni, A ms-nak... a mozillának...? Ugyan márAz ECMAScript fejlesztésének nem sok köze van az átgondoltsághoz. Sokan sokfelé vinnék, aztán az erősebb kutya veri a dobot. Így született az ES5, ami éppen annak az embernek volt legkevésbé ínyére, aki kitalálta az egészet egyáltalán. Eich már rég elvitte volna OO irányba az egészet, de a microhoo betartott akkor is. A googorola szvsz a legjobb lehetséges pártfogója a dolognak, de a megszokásokkal megküzdeni nem lesz egyszerű.
-
-
ddekany
veterán
Van egy olyan veszély, hogy nyelv annyira belerágja magát az ökoszisztémába, hogy bármennyire avétos és történelmileg cafatokra foltozott, esély sincs többé a kiütésére. Mondok egy tipikusat: C++ (pedig ott a DigitalMars D pl., de hát... nem lenne GC-s több esélye lenne, de továbbra is közel 0). A Java is remek úton halad efelé, a Ceylon/Kotlin elkéstek már, attól tartok (Scala is, de az túl okos is a célra). Na most lehet hogy a ECMAScript-el is így járunk... Annyi fejlesztés mindig lesz, hogy kifogja a szelet az új nyelvek vitorlájából annyira, hogy ne érje meg váltani. Hosszú távon persze ez a jelenség (régi nyelvek kiüthetetlensége) iszonyatos gazdasági károkat okoz összességében.
-
SlipOne
csendes tag
válasz
julius666
#20
üzenetére
jQuery-t addig használsz, míg nem egy komolyabb, nagyobb, erőforrás igényesebb alkalmazáson dolgozol, amit pl mobilon futtatsz. Természetesen elég beteg dolog, de mi írtunk egy keretrendszert alá, mert a jquerymobile és a sencha touch is csont lassú.
Saját kerettel, direkt figyelve az optimalizálásokra úgy 5-30x gyorsabb alkalmazásokat tudtunk vele előállítani. Nem mellesleg tudod, hogy nem megy bele felesleges láncokba semmi, csak abba, ami szükséges. -
#27
bambano
titán
Namelesske
#24
bambano
titán
válasz
Namelesske
#24
üzenetére
amellett, hogy (helyesen említették a platformfüggetlenséget), virtuális gépben könnyebb védekezni a programozók hibái ellen (tipikusan memóriakezelés, esetleg más is). másrészt nem feltétlenül lassabb, a vm akár többször is újraoptimalizálhatja futás közben a kódot. az tény, hogy a vm-es kód elég gyakran lassabban indul el, mint a natív.
-
#25
emvy
félisten
Namelesske
#24
válasz
Namelesske
#24
üzenetére
Igy lehet platformfuggetlennek lenni.
-
#24
Namelesske
addikt
Namelesske
addikt
Nagyon buta vagyok programozás témában, de mondja el nekem valaki miért éri meg Virtuális gépben futtatni a kódokat. Androidon is így vannak a dolgok. Nem lenne jobb magát a programot futtatni, nem pedig mindenféle rétegeket hozzá adni. Teljesítményre nincsen ez káros hatással? Valaki világosítson fel mert nekem csak az van amit kilogikázok.
Ja és azok kíméljenek akik csak egymás után bekommetelik, hogy hülye vagy, ha egy elkezdte.
-
SirRasor
addikt
JAh, az előbb utánaolvastam és elhültem
Viszont ha már annyi okos ember van itt, valaki elárulná, hogy flash szerű pl: játékot miben érdemes fejleszteni? Miben LEHET egyáltalán? HTML5? Eljárásokat, függvényeket, öö..mozzanatokat/szobákat/képkockákat..vagy mi a halálnak nevezzem, szóval izéket létrehozni? Tehát mintha programot írnék C#-ban vagy JAVA-ban, de a webbe ágyazva jelenjen meg, mint a flash.. Ötletek?
-
Sofian
őstag
"A JS olyan helyekre is beette már magát"...ahová soha nem lett volna szabad...
Ahogy többen fent emlegették a JS kezd valami köztes kódra hasonlítani, amit legszívesebben senki sem olvasna el.. (vagy nem is tud.. pl amit GoogleWebToolkit generál)... ehelyett sokkal jobb lenne valami alacsonyabb szintű java JVM vagy .net CLR szerű virtuális gép egy szabványos köztes kóddal.. aztán mindenki olyan nyelven dolgozik rajta amiből tud ilyen kódra fordítani... persze ehhez a HTML-t magát is felül kéne vizsgálni...
Majd a web 6.0...
-
julius666
addikt
Izé, most a html/css funkciókról van szó, vagy az ECMAScript-ről?
ECMAScript-ről.
ha viszont a nyelvek különböznek, az keményebb dió, emiatt nem érdemes gyors sikerre számítani
Annyira nem különböznek. Bizonyos featureök implementálhatóak a régebbi nyelven is (kvázi syntactic sugar-ök), max 1-2 ritka use caseben nem megfelelő a működésük/teljesítménybeli problémák. Bizonyos featureök visszafelé "kompatibilisek" (pl. strict mód). Bizonyos featureök esetleg nem megoldhatóak, ezek nyilván ugrottak. A nyelv maga maradt.
Ez legfeljebb azok a programozókra igaz, akiket te ismersz.
Nyilván van kivétel is bőven, de szerintem körbe lehet nézni a piacon. A webprogramozás klasszikusan nem az az igényes terület.
Ha van egy nyelv, ami mondjuk a Javascript-nél jobb (valamilyen metrikák szerint) és lehet belőle javascript-et fordítani, akkor mi a probléma?
Esetleges teljesítménybeli problémák, fejlesztési problémák (amit ntomka is említett illetve jó debuggolást).
És miért nem adnak a böngészők hasonló API-t?
Nálam hiába vered az asztalt, ez inkább a W3C meg a böngészőgyártók területe (verik is náluk elegen). A jQueryre szerintem nyugodtan mondhatjuk hogy kvázi-szabvánnyá vált, gyakorlatilag ezt használja mindenki.
-
#19
SirRasor
addikt
osztraksajt
#9
SirRasor
addikt
válasz
osztraksajt
#9
üzenetére
Mimimimimi? Most kezdtem Flasht tanulni, neidegelj már
Komolyan nincs jövője? JS-t nem ismerem, de flashben elég könnyű kb. bármit csinálni. -
cucka
addikt
Szerintem a kulcs az, hogy a Dart kódot át lehet fordítani Javascript kódra. Így a fejlesztő fejleszthet egy normális környezetben, a böngésző meg majd megeszi a Javascript-et ugyanúgy, ahogy eddig tette. Persze, ez csak elméleti lehetőség, soha nem fejlesztettem Dart-ban.
-
cucka
addikt
válasz
julius666
#10
üzenetére
Jelenleg is jelentősen jobb a helyzet mint pár éve csak mivel rengeteg funkciót a régebbi böngészők nem támogatnak
Izé, most a html/css funkciókról van szó, vagy az ECMAScript-ről? Az általában egy kezelhető dolog, ha egy böngésző nem tud valamilyen html/css funkcionalitást, ha viszont a nyelvek különböznek, az keményebb dió, emiatt nem érdemes gyors sikerre számítani.illetve a JS annyira mostohán van kezelve hogy a programozók jó része szarik ezekbe magasról, úgyis csak kopipasztázik valami template-t amit neten talált,
Ez legfeljebb azok a programozókra igaz, akiket te ismersz.Házi ökörködéshez lehet jó, éles projekthez én biztosan nem használnám.
Ha van egy nyelv, ami mondjuk a Javascript-nél jobb (valamilyen metrikák szerint) és lehet belőle javascript-et fordítani, akkor mi a probléma? A programok többsége lefordul valamilyen más nyelvre, mielőtt azt a számítógép le tudná futtatni.normális környezetben használva (pl. node.js) kiválóan működik.
A node.js-ről mindig a klasszikus mondás jut eszembe: "XML is a giant step towards no direction at all".Lásd jQuery, azt szokták már szeretni a programozók mert az értelmes API-t ad.
És miért nem adnak a böngészők hasonló API-t? Lehet, első körben ezen kéne dolgozni, nevetséges, hogy mennyire rá vannak szorulva a javascript fejlesztők a 3rd party könyvtárakra. -
.:LoMAX:.
aktív tag
Nem ide tartozik, de hasonló a helyzet a 29-es körzettel
.
Itt is a UPC csak fejte az előfizetőket, de fejlesztéseket nem végzett, de most, hogy a Digi elkezdett jó pár települést bekábelezni, a UPC is kezd kalimpálni, mint egy fuldokló, hogy ne veszítsen el azokon a helyeken az összes ügyfelet, és telefonálni, házalni kezdett, meg nevetséges kedvezményeket ajánlgat, ha marad a kedves ügyfél dupla árért és gyengébb netért .Még egyszer elnézést, hogy nem egészen ide tartozó, inkább a hasonlat, hogy mi történik, ha valaki csak alszik, és az "aranytojást tojó tyúkot" meg nem eteti
. -
#12
ntomka
nagyúr
osztraksajt
#9
ntomka
nagyúr
válasz
osztraksajt
#9
üzenetére
A flash-t nem ok nélkül utálják ki a webről. Van egy gazdája aki sz@rt hosszú évekig az egészbe, hát persze, hogy megutálta mindenki. Most persze elkezdett kapkodni, hogy mentse, de ugye ezt nem akkor kéne amikor már késő. Ahogy előttem is mondták, a JS legalább aktív és átgondolt fejlesztés alatt áll.
(#11) emvy: Mitől az a node.js?
-
válasz
julius666
#10
üzenetére
Nem webbel foglalkozom, de a node.js az egy vicc, az utobbi idok egyik legnagyobb szemfenyvesztese.
> Házi ökörködéshez lehet jó, éles projekthez én biztosan nem használnám.
Azert a GWT-t hasznaljak production kornyezetben is.Szoval en nem a Darts mellett kardoskodtam, hanem annyit mondtam, hogy a 'kozos' szabvanyfejlesztes altalaban semmit se er.
-
julius666
addikt
A kozos fejlesztesnek az a vege, mint a HTML5-nek: sosincs kesz, de legalabb a vegtelensegig huzodik.
A JS fejlesztése folyamatos, ha nem is fénysebességgel megy (úgy inkább ne is menjen, azt ugyanúgy nem lehetne átnyomni a webes társadalmon). Ha jól tudom jövőre be is fog érni a Harmony projekt ami talán a legnagyobb eddigi lépcsőfok lesz a folyamatban. Jelenleg is jelentősen jobb a helyzet mint pár éve csak mivel rengeteg funkciót a régebbi böngészők nem támogatnak (az ilyen Modernizr-féle cuccok overheadje meg sokszor nem éri meg) illetve a JS annyira mostohán van kezelve hogy a programozók jó része szarik ezekbe magasról, úgyis csak kopipasztázik valami template-t amit neten talált, így ez még a gyakorlatban nem jelent annyira meg.
Ezenkivul ugy latom, hogy JS-t lehet belole forditani, ami segithet.
Házi ökörködéshez lehet jó, éles projekthez én biztosan nem használnám.
Egyébként utánanézegettem régebben a darts-ot promotáló oldalukon mégis miféle dolog ez, hát meg kell mondjam, nem estem hasra tőle. Nem igazán látom mitől jobb ez annyival a JS-nél, sőt. De Douglas Crockford aki elég nagy tiszteletnek örvend a szakmában is hasonló véleményen volt mint én, ő talán még tovább is ment a jelzők terén
.Ezt így a Google helyében nem erőltetném annyira, a JS-el magával nincsenek akkora hatalmas nagy problémák (mint gyengén típusos dinamikus nyelv, akinek ez nem kenyere annak inkább a műfajjal van gondja), normális környezetben használva (pl. node.js) kiválóan működik. Inkább a különböző böngészős API-k azok amikkel a gond van. Lásd jQuery, azt szokták már szeretni a programozók mert az értelmes API-t ad.
-
#9
osztraksajt
őstag
osztraksajt
őstag
Szerintem meg 5 éve senki nem jósolta volna meg hogy a Flash előbb utóbb kimúlik, mint ahogy az már világosan látszik. Szóval várjunk még az elhamarkodott kijelentésekkel.
-
Kozosen nem lehet semmit sem fejleszteni. A kozos fejlesztesnek az a vege, mint a HTML5-nek: sosincs kesz, de legalabb a vegtelensegig huzodik. Ugy lehet tovabblepni, hogy csinalsz valamit, mogeraksz megfelelo tamogatast, toolingot, ha lehet, akkor nyitotta teszed.
Ezenkivul ugy latom, hogy JS-t lehet belole forditani, ami segithet.
-
#2
Apika
addikt
szabogabor10
#1
Apika
addikt
válasz
szabogabor10
#1
üzenetére
Én is kíváncsi vagyok, hogy mennyire fogadják el...
-
#1
szabogabor10
veterán
Kíváncsi vagyok, hogy mekkora sikere lesz. Mindenesetre nem lesz könnyű letéríteni a fejlesztőket a JS-ről.
)
) által elkövetett hibákat, ami igenis az ő idejükbe kerülnek a végén.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
"
Komolyan nincs jövője? JS-t nem ismerem, de flashben elég könnyű kb. bármit csinálni.
Új hozzászólás Aktív témák
Hirdetés
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- 27%-OS ÁFÁS SZÁMLA I Jogtiszta Microsoft digitális és fizikai termékek I DIGITALKEYZ.COM
- SZÜNETMENTES TÁPOK
- Samsung Galaxy Tab S6 Lite 64GB, Újszerű, 1 Év Garanciával
- MacBook felvásárlás!! MacBook, MacBook Air, MacBook Pro
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- LG 27GR95QL - 27" OLED / Limitált LoL Edition / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest