Keresés

Új hozzászólás Aktív témák

  • 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.

  • cucka

    addikt

    válasz bambano #16 üzenetére

    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 ddekany #57 üzenetére

    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.

  • cucka

    addikt

    válasz Integra #64 üzenetére

    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? :)

    [ Szerkesztve ]

  • cucka

    addikt

    válasz ddekany #65 üzenetére

    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.

  • cucka

    addikt

    válasz ddekany #73 üzenetére

    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 :D ), de ha a hobbiprojektedhez szeretnél hosting szolgáltatót, akkor elég kevés a lehetőség.

  • cucka

    addikt

    válasz Integra #70 üzenetére

    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

    válasz ddekany #84 üzenetére

    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?

    [ Szerkesztve ]

  • cucka

    addikt

    válasz bambano #94 üzenetére

    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?
    Nosztalgikus :D

    de 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ó :D (nem bántásból, csak a gondolatmeneted erről árulkodik)

    [ Szerkesztve ]

  • cucka

    addikt

    válasz ddekany #117 üzenetére

    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 :)

    [ Szerkesztve ]

  • cucka

    addikt

    válasz bambano #131 üzenetére

    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.

  • cucka

    addikt

    válasz ddekany #134 üzenetére

    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.

  • cucka

    addikt

    válasz bambano #155 üzenetére

    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.

    [ Szerkesztve ]

  • cucka

    addikt

    válasz bambano #165 üzenetére

    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..

    [ Szerkesztve ]

  • cucka

    addikt

    válasz ddekany #168 üzenetére

    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.

  • cucka

    addikt

    válasz ddekany #175 üzenetére

    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 :D )

    Egyébként meg tessék, V8 engine php alá, lehet kezdeni ismét a rettegést meg a szörnyülködést :)

Új hozzászólás Aktív témák