BGAFC Vendégkönyv

Σ: 16 post

kemi (statz)

#2, Főfasz (2970)

57 | #1bd0 | ^ | Idézet | Mon, 16 Apr 2012 07:11:22 +02

178.164.*.*

*.pool.digikabel.hu

Köszi, ez még hasznos lehet, mert programozok még C#-ban.

Prometheus (statz)

#3, Főfasz (1824)

296 | #1bd1 | ^ | Idézet | Mon, 16 Apr 2012 11:31:32 +02

84.0.*.*

*.dsl.pool.telekom.hu

Kecskebaszók, olvastam, hogy van egy oldal, a Spedia, ami föltelepít egy bannert, és minél többet mozgatom rajta az egeret (egy programmal), annál több pont gyűlik össze, amit később pénzre válthatok. Ez sajnos már elég régi, de ti talán tudtok aktuálisat, hogy lehet az Interneten pénzt keresni.

kemi (statz)

#2, Főfasz (2970)

26 | #1bd2 | ^ | Idézet | Mon, 16 Apr 2012 11:43:25 +02

193.224.*.*

*.uni-obuda.hu

Ez eléggé kamunak hangzik.

djpety alias "Pety"

#6, Lófasz (953)

21 | #1bd3 | ^ | Idézet | Mon, 16 Apr 2012 11:50:19 +02

84.225.*.*

*.pool.telenor.hu

Az összes ilyen kamu.

TCH (statz)

#1, Főfasz (10443)

4132 | #1bd4 | ^ | Idézet | Mon, 16 Apr 2012 12:43:24 +02

46.107.*.*

*.catv.pool.telekom.hu

saxus írta/wrote:
Az osztogatásos módszer elég favágó módszer.

1. hülye vagyok a matekhoz, 2. faszom se akart prímeket keresni, kemi ki akarta mérni, hogy melyik bloatware a bloatabb, a ciszta, vagy a dzsuva.

saxus írta/wrote:
Miután a jittereket (és a sima statikus fordítókat is egyre okosítják -) felkészítik arra, amit tipikusan írnak az emberek, így egy-egy mikrooptimalizációval sokszor sokkal-sokkal többet árt az ember.

Ezér' köll assemblerben tolni. :P

saxus írta/wrote:
"Hatékony .NET"

Úristen. Már a cím is oximoron.

saxus írta/wrote:
mind a Java, mind a .NET jól kioptimalizálja

Mit értesz optimalizáció alatt? Hogy csak 250x lesz lassabb, mintha C-ben vagy C++-ban írtad volna meg, nem 350x? Egy elméleti kérdés...mi a rákért tolod ilyen bloat nyelvekben? Ha utálod a C-t a fapadsága miatt, akkor miért nem C++ vagy Delphi?

saxus írta/wrote:
Java esetén egyébként nem tudom mi a helyzet, de a tapasztalatom az, hogy ott is lehet gyors dolgot fejleszteni, csak akarni kell.

F99 írta/wrote:
De hát ha egyszer valami javás, azon a jóisten összes mips-e sem segít, kattintás után sokáig nem lehet eldönteni, hogy azért nem történik semmi, mert megint megfagyott a böngészőablak, vagy csak a Power-processzorok hugyoznak vért, hogy előállítsák azt a kék csíkot meg a hat sor szöveget.

Nem beszólni, hogy hét éves sztori. Ez azóta sem változott.

Prometheus írta/wrote:
Kecskebaszók, olvastam, hogy van egy oldal, a Spedia, ami föltelepít egy bannert, és minél többet mozgatom rajta az egeret (egy programmal), annál több pont gyűlik össze, amit később pénzre válthatok.

XDDDDDDDDDDDDDDDDDDDDD
Figy Prometheus, én tudok jobbat! Felteszed azt a programot, amit adok neked és az mindenféle tevékenység nélkül pontokat fog neked termelni, amit aztán beválthatsz pénzre! Na felrakod? :D

Prometheus írta/wrote:
Ez sajnos már elég régi, de ti talán tudtok aktuálisat, hogy lehet az Interneten pénzt keresni.

Hogyne tudnánk. Kedves Prometheus a neten ugyanúgy lehet pénzt keresni, mint bárhol másutt az univerzumban és ugyanúgy nem fogsz találni.
De félretéve a szóvicceket a neten tényleg ugyanúgy lehet pénzt keresni, mint a való életben. Munkával. Persze dettó, mint a való életben itt is átbaszhatnak, szóval jól nézd meg, hogy kitől és mit vállalsz el.
Az ilyen feltelepítesz valamit és dől a pénz, vagy megnyitsz egy honlapot és nézed és dől a pénz maszlagokat meg ne hidd el, ez mindegyik átverés. Legjobb esetben csak valami ostoba tréfa és feleslegesen basztál el vele időt, legrosszabb esetben pedig valami kártékony program (botnet client, spyware vagy akár vírus) és vagy átveszik a géped felett az irányítást, vagy csak ellopkodják az érzékeny adataidat amit neten keresztül használsz (jelszó, pinkód, stb.). Honlapnézés esetén meg esetleg csak annak dől a pénz, akinek az oldalán bámulod a reklámokat.
Szal, felejtsd el ezeket.
A szerencsejátékokat szintén, mind a neteset, mint a valóságosat. Az is mind átverés. Lehet rajtuk nyerni ja, kurwasok próbálkozás után, a nagy számok törvénye alapján előbb utóbb nyersz. Pl. mire nyernél az ötöslottón, addigra a sokszorosát költenéd rá a szelvényekre.

Szóval ha pénzt akarsz, akkor dolgoznod kell, mert könnyű pénz NINCS. Max, ha az utcán találod, vagy ha öröklöd. :P

Megjegyzem a lopás is munkával jár, szóval betöréssel vagy politikuskodással sem könnyű pénzt keresni, mert a betörő a bőrét viszi vásárra, a politikus meg mire eljut oda, hogy dől a lé, addigra nagyon sok segget ki kell nyalnia és nagyon sok mindenkit meg kell kennie. Ennyi erővel, ugyanott vagy ha kitalálsz egy ötletet, amire vevők az emberek és megvalósítod, mert ugyanúgy dőlni fog a lé, de ugyanúgy melózni kellett hozzá.
Summa summárum, hacsak nem találsz vagy örökölsz pénzt, a melót nem fogod megúszni.

kemi (statz)

#2, Főfasz (2970)

259 | #1bd5 | ^ | Idézet | Mon, 16 Apr 2012 14:44:58 +02

94.21.*.*

*.pool.digikabel.hu

Ami még rosszabb, hogy ugye ehhez be kell regisztrálnod valahova. Amellett, hogy felrak mindenféle spywaret, még a személyes adataiddal is visszaélhetnek, sőt gondolom egy bankszámlaszámot is elkér, akkor még a pénzedet is lenyúlhatják. Ne dőlj be ilyeneknek.

saxus (statz)

#9, Agyfasz (419)

634 | #1bd6 | ^ | Idézet | Mon, 16 Apr 2012 17:12:08 +02

0.0.*.*

*.kgb.gov.su

TCH írta/wrote:
Mit értesz optimalizáció alatt? Hogy csak 250x lesz lassabb, mintha C-ben vagy C++-ban írtad volna meg, nem 350x?

Ha a C-be is berakod mindazokat az ellenőrzéseket, amelyeket a JVM vagy a CLI elvégez helyetted (pl. tömbindex ellenőrzés, rakás memóriakezelés, rakás egyéb cucc, akkor az a kód is ugyanolyan lassú lesz.

Szimpla matekban se a Java se a .NET nem lassabb, mint a C. Különbség a körítésben van. Azt meg a jóisten se fizeti meg nekem, hogy írjak mondjuk egy 2x gyorsabban lefutó kódot, ha
a) elhanyagolható a megspórolt hardver.
b) költség legalább 5-10x-ese lesz.

TCH (statz)

#1, Főfasz (10443)

1955 | #1bd7 | ^ | Idézet | Mon, 16 Apr 2012 18:45:55 +02

80.98.*.*

*.catv.broadband.hu

saxus írta/wrote:
Ha a C-be is berakod mindazokat az ellenőrzéseket, amelyeket a JVM vagy a CLI elvégez helyetted (pl. tömbindex ellenőrzés, rakás memóriakezelés, rakás egyéb cucc, akkor az a kód is ugyanolyan lassú lesz.

Ez nem igaz. Akkor lenne ugyanolyan lassú, ha C-ben a C#-el vagy Java-val megegyező adatszerkezeteket és eljárásokat használnál. C-ben te állítod össze a teljes adatszerkezetet és a hozzá tartozó funkciókat, ennek megfelelően nem kerülnek bele felesleges kerülők, ellenőrzések, tárolások, rutinok, stb. C-ben az int x egy sima integer, míg C#-ben rögtön hozzárendel minden szemetet, holott nem biztos, hogy kértem.

saxus írta/wrote:
Szimpla matekban se a Java se a .NET nem lassabb, mint a C.

Dehogynem. Szükségszerűen az adatok kezelésének felesleges kerülői miatt.

saxus írta/wrote:
Azt meg a jóisten se fizeti meg nekem, hogy írjak mondjuk egy 2x gyorsabban lefutó kódot, ha

Nem 2x olyan gyors lesz a kód, hanem többször.

saxus írta/wrote:
a) elhanyagolható a megspórolt hardver.
b) költség legalább 5-10x-ese lesz.

Na igen. Ez a két "indok" gyakorlatilag az a két kifogás, ami a szoftverek brutális elhízásához vezetett. Ez az erőforráspocsékoló úgy is bírja a hw, vagy ha nem majd raknak alá vasat mentalitás az egyik, a sóher és lusta így sokkal gyorsabban és sokkal kevesebből megvan mentalitás meg a másik aminek eredménye, hogy a szoftverek egyre lassabbak és nagyobbak lesznek, de ez nem fog a végtelenségig tartani.

Niklaus Wirth írta/wrote:
Software is getting slower more rapidly than hardware becomes faster.

A holdra egy C64 kaliberű géppel feljutottak és ma ennek a teljesítménynek a többszázezerszeresére van szükség, hogy a windózpécé életre keljen. No fuckin comment.

kemi (statz)

#2, Főfasz (2970)

399 | #1bd8 | ^ | Idézet | Mon, 16 Apr 2012 21:18:24 +02

94.21.*.*

*.pool.digikabel.hu

Lefuttattam egy prímkeresős benchmarkot, C-n, Javán, meg C#-on. A C vesztett, de az valószínűleg azért van, mert fos a GCC winfoson. :P A Java viszont megint nyert, tehát kijelenthetjük, hogy a .NET még a Javánál is fosadékabb.

C:\Users\kemi242>primec
91

C:\Users\kemi242>primecs
89

C:\Users\kemi242>java -jar prime.jar
85

C:\Users\kemi242>

saxus (statz)

#9, Agyfasz (419)

4964 | #1bd9 | ^ | Idézet | Mon, 16 Apr 2012 22:10:05 +02

84.3.*.*

*.catv.pool.telekom.hu

kemi írta/wrote:
de az valószínűleg azért van, mert fos a GCC winfoson.

Nem csak ott ;) Nem véletlen, hogy komoly pénzeket tolnak egyes cégek az LLVM+Clang páros fejlesztésébe. Ugyan átlagosan még jó 10%-al lassabb a GCC-nél a generált kód, csak épp kevésbé bloated, sokkal modernebb, modulárisabb arch (egy optimalizer, amögött archonként konkrét fordító + optimalizáló, a fordító előtt meg nyelvenként frontend, amely a fordító köztes nyelvére fordít. Így egy új nyelv támogatásakor csak a nyelv->köztes kód fordítót kell megírni, nem kell mindenhol optimalizálót, stb. Nem tudom, ismerős-e valakinek a JVM/CLI koncepciója itt ;) Ja meg jóval értelmesebb hibaüzenetek. Szóval itt is az van, hogy az esetek nagy részében nem éri meg az a plusz 10% (na meg figyelembe véve, hogy néhány éve sehol nem volt a projekt, egyáltalán nem biztos, hogy nem fogja csúnyán lehagyni idővel a GCC-t).

kemi írta/wrote:
A Java viszont megint nyert, tehát kijelenthetjük, hogy a .NET még a Javánál is fosadékabb.

Az ilyen szintetikus tesztek így önmagukban semmit nem mondanak. Másrészt a Java meg a .NET nem matekolásban lassabb, mint a C, hanem pl. a dinamikus dolgok használata miatt. Pl. reflection.

TCH írta/wrote:
hogy a szoftverek egyre lassabbak és nagyobbak lesznek, de ez nem fog a végtelenségig tartani.

Öregem, a helyzet az, hogy a CPU-k magjainak száma másfél évente megduplázódik. Ezzel együtt kb. a teljesítményük is. Ehhez képest disk, a hálózat vagy úgy bármiféle IO sebességének fejlődése kb. a vánszorgó csiga tempója. Az a helyzet, hogy ha _alkalmazást_ akarok fejleszteni, ahol a cél egy konkrét (nem informatikai) probléma megoldása, akkor kb. totálisan telibe fogom szarni, hogy egy gomb eseménykezelője most 0.1 vagy 0.2 microsecig futott. User nem vesz észre belőle semmit és egyébként is, a CPU idő 99,99%-a kihasználatlan.

TCH írta/wrote:
Dehogynem. Szükségszerűen az adatok kezelésének felesleges kerülői miatt.

Látszik, hogy nem olvastad el a linkelt cikkeket. Másrészt, hibakezelést nem lehet elsunnyogni. Az a helyzet, hogy a legtöbb fagyás és sechole még mindig az ilyenekből adódik.

TCH írta/wrote:
Ez a két "indok" gyakorlatilag az a két kifogás

Vedd még hozzá a csapatban való fejlesztést és a kódok továbbadását. Pont most anyázok amiatt, hogy az a kedves kolléga, aki 4 hónap után dobbantott és egy önfejű makacs fasz volt szakmai téren nekiállt "leszarom, ez így fos, nem érdekel, gány fúj, nem vagyok hajlandó így kódolni" hozzáállással telibetúrni a rendszert és a meglévő rendszerkomponensek helyett egyedi módon megoldani a feladatot. Hozománya? A fejlesztést segítő toolok 100%-a nem működik együtt a cuccaival, AJAX réteg megkerülve, +1 template rendszer. "Mert gyorsabb így." Kurvára kibaszottul leszarom, főleg, hogy dobbantott. Most ez azzal járt, hogy tarthatok karban kettő dolgot és akinek be kell tanulnia a rendszerbe, és egy ilyen az keményen megnöveli a betanulást és az időt, amely alatt egy hibát javítani lehet. Na ez az idő egy ember esetén átlagosan egy fél szerver ára.

Ha alkalmazást fejlesztesz, ott kell optimalizálni, ahol gázos a teljesítmény, egyébként minden esetben kizárólag az számít, hogy könnyen áttekinthető és rugalmas

TCH írta/wrote:
Akkor lenne ugyanolyan lassú, ha C-ben a C#-el vagy Java-val megegyező adatszerkezeteket és eljárásokat használnál.

legyen a kód.

Hagyjuk már, C-ben önmagában lófasz nincs. Azt különben is rendszerprogramozásra találták ki, nem alkalmazásfejlesztésre. Másrészt, amint összefutsz C-ben ilyen - manapság elég általános - feladatokkal, mint memoriakezelés (.NET pl. képes arra, hogy áthelyezzen memóriában részeket, hogy ne legyen annyira fragmentált, így gyorsabban lehet foglalni vs. malloc(), ami szanaszét tudja töredezni a ramot) vagy esetkeg [unicode/utf8/ansi] stringkezelés, neadjisten XML feldolgozás, mindjárt ott tartunk, hogy hoppá.

Aztán ha meg eljutunk ilyen apróságokig, amire nemigazán illik a "non blocked" jelző, mint disk vagy hálózati művelet, máris gyakorlatilag elenyésző a különbség. Hisz egy IO művelet esetén a kód 99%-a úgy is az OS kódja lesz vagy valószínűbb, hogy vársz a hardverre.

TCH írta/wrote:
A holdra egy C64 kaliberű géppel feljutottak és ma ennek a teljesítménynek a többszázezerszeresére van szükség, hogy a windózpécé életre keljen. No fuckin comment.

Remek, a 60-70-es évek informatikájával szemben meg nem változott semmi, ugye? Tegyük már hozzá, hogy ahhoz a teljesítményhez kellett 3 szobányi szekrény, ma meg körberöhögi a mobilom és akkor még grafikont is rajzol az adatokból valós időben meg még kielemzi és nem két év alatt van meg hozzá a szoftver, hanem 3 hónap alatt.

TCH (statz)

#1, Főfasz (10443)

9349 | #1bda | ^ | Idézet | Tue, 17 Apr 2012 01:35:46 +02

46.107.*.*

*.catv.pool.telekom.hu

kemi: Próbáld ki Delphivel is, kiváncsi vagyok az mit dob.

saxus írta/wrote:
Öregem, a helyzet az, hogy a CPU-k magjainak száma másfél évente megduplázódik. Ezzel együtt kb. a teljesítményük is.

Ennél nagyobb marhaságot már rég hallottam, "öregem". Látszik hogy közöd nincs a processzorokhoz. A több mag csak párhuzamosítható feladatoknál jelent nagyobb teljesítményt, amúgy kb. semmit sem jelent, hogy amúgy tudna több szálon is dologozni, márpedig a programok javarésze nem párhuzamosítható csak úgy, az egymás eredményeire épülő részek, az elágazások nem lesznek párhuzamosak. Ott eredményez teljesítménynövekedést, ahol számít a szálak száma, mert egyszerre több egymástól független szál fut (oprendszerben a programok, rendering, uncompress, mittom).

saxus írta/wrote:
Az a helyzet, hogy ha _alkalmazást_ akarok fejleszteni, ahol a cél egy konkrét (nem informatikai) probléma megoldása, akkor kb. totálisan telibe fogom szarni, hogy egy gomb eseménykezelője most 0.1 vagy 0.2 microsecig futott.

Vetítsd ki hosszútávra és vetítsd ki az egész programra. Ha egy szar gomb benyomása is több erőforrást eszik meg, akkor mi lesz az erőforrásigényes részekkel? Semmi, Javaban megírva ötször olyan lassú lesz, mint mondjuk Delphiben.

saxus írta/wrote:
a CPU idő 99,99%-a kihasználatlan.

Otthoni gépen, ahol csak passziánszoznak, ja. De ahol munka folyik, ott csaknemtán.

saxus írta/wrote:
Ha alkalmazást fejlesztesz, ott kell optimalizálni, ahol gázos a teljesítmény,

Néha kénytelen megkerülni az ember a hulladék frameworköket. Engem basztak már le azért, mert a Codeigniterben kikerültem a querybuildert (nem a DB layert) és

$this->db->select(xxx);
$this->db->from(yyy);
$this->db->where(zzz);
$this->db->execute();

helyett beírtam, hogy

$this->db->query('select xxx from yyy where zzz');

A benchmark szerint 5x (!) olyan gyorsan futott, de egyébként nem is ez volt az ami miatt csináltam, hanem azért, mert a querybuilder where paramétere nem támogatta a zárójelezést. Vagyis a feladat nem volt megoldható vele. Néha komolyan úgy érzem, hogy a keretrendszer csak arra jó, hogy keretek közé szorítsa az embert. Demertatöbbikollégaislássaát. Tanuljon meg JIT kódot értelmezni, vagy húzzon kapálni, így is sok a dilettáns programozó, különben is, aki nem ért egy szaros SQL lekérést, az a framework apiján keresztül átadott ojjektumhívásokat se fogja...
Mielőtt félreértenéd, nem az ex-kollégádat védem, csak elmeséltem egy pofáraesést egy ilyen csodakeretrendszerrel.

saxus írta/wrote:
Látszik, hogy nem olvastad el a linkelt cikkeket.

Megdögleni sincs időm, most estem haza. Majd. De ha azt írják, hogy a Java gyorsabb, mint a C/C++ vagy a Delphi, akkor felesleges...

saxus írta/wrote:
Másrészt, hibakezelést nem lehet elsunnyogni.

Ki akarja elsunnyogni, könyörgöm! De hibakezeléstől nem lesz 100x akkora a kód sem C-ben/C++-ban, sem Delphiben! Disassembláld már egyszer, amit Java-ban kapsz és nézd meg, mennyi felesleges marhaságot belefordít!

saxus írta/wrote:
Hagyjuk már, C-ben önmagában lófasz nincs.

Az ilyen beszólásokra te a szövegértés egyes kitételt szoktad használni, én inkább elmondom, hogy egyfelől a C-t csak példának hoztam fel, mondhattam volna C++-t meg Delphi-t is, másfelől meg azért vannak a könyvtárak ezekhez a nyelvekhez, hogy használd őket, nem hogy mindent nulláról írj meg. Persze egy pucér C fordító az tényleg lófasz... (Zárójelben mondom, hogy C könyvtár alatt nem az atomhulladék libcét értettem.)

saxus írta/wrote:
Azt különben is rendszerprogramozásra találták ki, nem alkalmazásfejlesztésre.

Ebben igazad van, de most mondtam, hogy csak példa volt. A C++ vagy a Delphi az kurwára alkalmazásfejlesztésre van. Ne akard nekem bemagyarázni, hogy egy minden szarral ellátott C++ vagy egy megszámlálhatatlan Unittal települő Delphi, amiben pikpak össze lehet kattingatni még a GUI-t is, az több fejlesztési időt enne meg, mintha Java-ban csinálnád ugyanazt, nem is beszélve a végeredmény sebességéről.

saxus írta/wrote:
Másrészt, amint összefutsz C-ben ilyen - manapság elég általános - feladatokkal, mint memoriakezelés (.NET pl. képes arra, hogy áthelyezzen memóriában részeket, hogy ne legyen annyira fragmentált, így gyorsabban lehet foglalni vs. malloc(), ami szanaszét tudja töredezni a ramot)

Megint csak azt mondom, hogy a C csak egy példa volt, de amúgy, ha virtuális memóriaáthelyezéssel csinálja a .NET, akkor az C-ben is megy, lévén az nem szoftveres, hanem az MMU műve. Ha meg nem, akkor meg elárulom, hogy az áthelyezés nyilván nem fog kimerülni egy szaros allokálásban a C részéről sem, attól függ, hogy írod meg a memóriakezelést, a lényeg, hogy rajtad áll, nem a kurwa keretrendszeren múlik. Persze, ha nem akarsz szarakodni, akkor könnyebb odavágni a cuccnak, de elhiheted, hogy C-ben is meg lehet ugyanazt írni, csak tovább tart. (A .NET-et se .NET-ben írták. :P) De mondom a C csak példa. Ott a C++ vagy Delphi. Azokban van szofisztikált memóriakezelés is a streamoktól elkezdve minden fosig.

saxus írta/wrote:
Hisz egy IO művelet esetén a kód 99%-a úgy is az OS kódja lesz vagy valószínűbb, hogy vársz a hardverre.

Nem csak I/O műveletek vannak, ott kb. majdnem tényleg mindegy mi a fáras hívta meg. De pl. direkt adatmanipulációnál, már számít, hogy az adatokon milyen gyorsan ügyködik a cucc. És nem a C/C++/Delhi lesz a lassabb.

saxus írta/wrote:
Remek, a 60-70-es évek informatikájával szemben meg nem változott semmi, ugye?

Mondtam én ilyet? Mondjuk a szoftverek egy jelentős része nem változott annyit, mint amekkora teljesítménynövekedést igényel! Pl. játékok. Ott van az az angribörc nevű izé. Akár SNES-en is futhatna egy ilyen játék, csak meg kéne írni.

saxus írta/wrote:
Tegyük már hozzá, hogy ahhoz a teljesítményhez kellett 3 szobányi szekrény

Történelem karó. Bocs, hogy szétpukkasztom ezt a buborékot, de tessék itt az Apollo Guidance Computer:
http://en.wikipedia.org/wiki/Apollo_Guidance_Computer
Dimensions 24x12.5x6.5 inches (61x32x17 cm)
3 szobányi szekrény? Ez akkora, mint egy mai pécé. Miről is beszélsz?

saxus írta/wrote:
ma meg körberöhögi a mobilom és akkor még grafikont is rajzol az adatokból valós időben meg még kielemzi

Ezt mind? Kajakra? Fél évszázad alatt ezt mind sikerült elérni többezerszeres órajelnövekedés és többmilliószoros memórianövekedés mellett? Öcsém beszarok...hihetetlen mire képes ez a kurwa informatika manapság.

saxus, úgy látom teneked kurwára nincs fogalmad arról, hogy mi mindent tudtak már azok a régi "szar" gépek is. Kurwa sok mindent, csak bilgéc elhitette a világgal, hogy ő fosta a Niagara vízesést és pécén találtak ki mindent. Hát nem. Egy nagy lófaszt. Pl. a mostanság kurwára divatos MVC modell is 30 éves, csak valami hülye kitalálta, hogy ez valami nagyon új dolog és ezért nagyon modern, meg nagyon menő.

De nézhetjük azt a fene divatos 3D-t is. Emlékszel az egyik vesszőparipámra; neked nem kell bemutatnom a Babylon 5-öt. Negyed évszázaddal ezelőtt is komplett sorozatokat rendereltek le 3D-ben.
Ehhez képest ma maximum nagyobb lett a felbontás és esetleg kevésbé szögletes a mozgás, mert gyorsabban renderelnek le több fázist. Na, de ennyit sikerült az elmúlt húsz év alatt a többszázszoros órajelnövekedésért és többezerszeres memórianövekedésért cserébe összehozni?

Kurwára nem fejlődtek annyit a szoftverek, mint amennyi vasat megzabálnak. Csak sajnos manapság minden hülyének lehet gépe, sőt programozhat is rajta és ezek a vérpistikék elöntöttek mindent, de nem baj, mert két év helyett három hónap alatt is összedobják a szoftvert, az űrhajó meg majd leesik, mert lefagy a winfoshétfónon a dzsuva és vele a kernel is, bocs csak ehhez értünk, dehát ez még grafikont is rajzol ríltájm. Dikmá, én is tudok szarkasztikus lenni? Mik vannak...

És annak eredménye, hogy feltelt baromállatokkal a szakma, annak eredménye ez a sok seggnyaló nyelv, ami lassan már megírja a programot az ember helyett és hogy minden le legyen kezelve, hogy a programozónak semmire ne kelljen ügyelnie (minek akkor programozó?! akkor kattintgassa össze a titkárpicsa!), beleforgat annyi védelmi mechanizmust, hogy a gép beszarik, mire ezek a programmonstrumok egyet moccannak.

Szerintem te túl sok szakkönyvet olvastál és az agyadra ment. Elhitted, amit összehordanak, de a mélyére nem néztél, mert minek, azt megoldja a ciszta meg a dzsuva. Faszom az egész mai programozótársadalomba.
Most nézd meg micsinátá' megint idehordtam öt tonna fasságot, ahelyett, hogy aludnék. :P

Más. Most szoptam egy sort órákül databézzel. Te futottál már vele össze? Van valami értelmes indoka annak, hogy nincs benne LIMIT parancs, hanem helyette egy a nyelvbe bedrótozott oszlopot kell belehákolni a WHERE klauzába? (Ami ráadásul mindig 1-ről indul, szóval, ha lapozni akarok, akkor egymásba ágyazott kéréseket kell írnom. :P ) Vagy ez csak a demoverzió, a pénzesben nincsenek ilyen fasságok? :P

kemi (statz)

#2, Főfasz (2970)

949 | #1bdb | ^ | Idézet | Tue, 17 Apr 2012 09:45:33 +02

193.224.*.*

saxusnak annyiban igaza van, hogy ha mondjuk sokan dolgoznak egy nagy projekten, OO nyelven írsz egy modult, akkor azt mások úgy fel tudják használni, hogy nem kell tudniuk semmit a megvalósításról, meg az OO nyelven írt kód sokkal jobban karbantartható. Ha meg az egészet C-ben írnák meg, az optimalizációkkal együtt totális káosz lesz az egész kód azon ember legyen aki el tud igazodni. :P Viszont C-ben egy int az tényleg egy int, míg a C# egy csomó szemetet eltárol mellé. Az meg, hogy a compiler optimalizál helyetted, sajnos oda vezet, hogy képzett programozók helyett "betanított munkásokat" alkalmaznak, ami mégjobban a szofterek elhízásához vezet.

http://hu.wikipedia.org/wiki/Szoftverek_felf%C3%BAv%C3%B3d%C3%A1sa írta/wrote:
Másik ok, hogy a kizárólag matematikusok és mérnökök helyett lehetővé vált széles tömegek számára, hogy szoftvert fejlesszenek komolyabb előképzettség nélkül.

TCH (statz)

#1, Főfasz (10443)

1873 | #1bdc | ^ | Idézet | Tue, 17 Apr 2012 11:09:42 +02

46.107.*.*

*.catv.pool.telekom.hu

kemi írta/wrote:
saxusnak annyiban igaza van, hogy ha mondjuk sokan dolgoznak egy nagy projekten, OO nyelven írsz egy modult, akkor azt mások úgy fel tudják használni, hogy nem kell tudniuk semmit a megvalósításról,

Imperatív módon is meg lehet írni a modult, ha függvényeket kapnak, ugyanúgy nem kell tudniuk semmit sem a belső működésről.

kemi írta/wrote:
meg az OO nyelven írt kód sokkal jobban karbantartható.

Ez sem feltétlen igaz. Fel lehet építeni ojjektumok nélkül is, úgy hogy átlátható legyen. Egyébként megsúgom, hogy ha oop módon írod meg, akkor is függvényeket fogsz meghívogatni, csak előtte konstruktor, utána meg destruktor, meg néhány felesleges kör és a végén úgyis gotokra és pointerekre fordul az egész, hogy saxust parafrazáljam. :P
Egyébként melyik az átláthatóbb szerintetek?

x = new akarmi()
x->setvalami(y)
x->setvalamimas(z)
x->setmegvalami(abc)
x->csinaljvalamitbazdmeg()
x->disztroy()

vagy

csinaljvalamitbazdmeg(y, z, abc)

?
Ugye ez nem is kérdés. De ha valakinek az első setezmegaz jobban bejön, azt is meg lehet csinálni sima változókkal meg tömbökkel és egy sima memóriaindexelés (tömb) gyorsabb lesz, mint az ojjektum.

kemi írta/wrote:
Ha meg az egészet C-ben írnák meg, az optimalizációkkal együtt totális káosz lesz az egész kód azon ember legyen aki el tud igazodni. :P

Ne kezdd te is, plz. A C csak példa volt. Ott a C++ meg a Delphi.

kemi írta/wrote:
Az meg, hogy a compiler optimalizál helyetted, sajnos oda vezet, hogy képzett programozók helyett "betanított munkásokat" alkalmaznak, ami mégjobban a szofterek elhízásához vezet.

Ööö...hát én is eszontam, csak én tíz oldalon keresztül. :P Néha szószátyár vagyok, na. :P

kemi (statz)

#2, Főfasz (2970)

768 | #1bdd | ^ | Idézet | Tue, 17 Apr 2012 11:41:21 +02

193.224.*.*

TCH írta/wrote:
Ez sem feltétlen igaz. Fel lehet építeni ojjektumok nélkül is, úgy hogy átlátható legyen. Egyébként megsúgom, hogy ha oop módon írod meg, akkor is függvényeket fogsz meghívogatni, csak előtte konstruktor, utána meg destruktor, meg néhány felesleges kör és a végén úgyis "gotokra és pointerekre fordul az egész", hogy saxust parafrazáljam. :P
Egyébként melyik az átláthatóbb szerintetek?
x = new akarmi()
x->setvalami(y)
x->setvalamimas(z)
x->setmegvalami(abc)
x->csinaljvalamitbazdmeg()
x->disztroy()
vagy
csinaljvalamitbazdmeg(y, z, abc)

akarmi x = new akarmi(y, z, abc);
x.csinaljvalamitbazdmeg();
//az x.disztroy()-t majd a szemétgyűjtő meghívja

TCH (statz)

#1, Főfasz (10443)

466 | #1bde | ^ | Idézet | Tue, 17 Apr 2012 13:52:35 +02

80.98.*.*

*.catv.broadband.hu

kemi írta/wrote:

akarmi x = new akarmi(y, z, abc);
x.csinaljvalamitbazdmeg();
//az x.disztroy()-t majd a szemétgyűjtő meghívja

És ennek így mi értelme is van? Minek csinálok egy objektumot? A garbage collectoros kitételt meg hagyjuk. Én nem bíznék szemétgyűjtést sem a dzsuvára, sem a cisztára. Hovatovább, kézzel felépített adatszerkezet megfelelő kezelése mellett, nincs szükség semmiféle garbage collectionra.

saxus (statz)

#9, Agyfasz (419)

6130 | #1bdf | ^ | Idézet | Tue, 17 Apr 2012 15:00:53 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
kemi: Próbáld ki Delphivel is, kiváncsi vagyok az mit dob.

Tippre lassabb lesz, mint a C. Anno nézegettem, hogy melyik fordító mit optimalizál ki és mit nem (BDS2005, C#2.0 v C#3.5, MSVC++2005 v 2008, már nem emlékszem). Hát... C++ -hoz képest a BDS triviális dolgokat sem feltétlen optimalizált ki.

TCH írta/wrote:
A több mag csak párhuzamosítható feladatoknál jelent nagyobb teljesítményt, amúgy kb. semmit sem jelen

Uhum, és azért a ciklus az egy viszonylag ritkán használt fogalom ugye? Attól, hogy jelenleg minden arra van ráálva, hogy egy szálon csinálsz mindent (UI Thread ismerős valakinek?), attól még szépen lassan el lehetne kezdeni gonodlkodni azon, hogy mit hogyan lehet párhuzamosítani. Meglehetősen sok mindent lehet.

TCH írta/wrote:
akkor mi lesz az erőforrásigényes részekkel?

Write only? Az erőforrásigényes részekre kell koncentrálni nem azokra, amelyeknél tökmindegy.

TCH írta/wrote:
hogy egyfelől a C-t csak példának hoztam fel, mondhattam volna C++-t meg Delphi-t is

Delhpi VCL egy baromi nagy réteg a Windows saját GUI-ja felett, amelyet - breaking news - sokáig tart inicializálni egy MFC-hez képest. ;) Csak épp mindenki leszarja, mert annyival nem lassabb, mint amennyivel gyorsabb vele dolgozni. WinForms, WPF detto, főleg, hogy a WPF a WinFormshoz képest képes kihasználni a DirectX-et is.

TCH írta/wrote:
Ne akard nekem bemagyarázni, hogy egy minden szarral ellátott C++ vagy egy megszámlálhatatlan Unittal települő Delphi, amiben pikpak össze lehet kattingatni még a GUI-t is, az több fejlesztési időt enne meg, mintha Java-ban csinálnád ugyanazt, nem is beszélve a végeredmény sebességéről.

Na de mennyi CPU időt vesz el az a sok lib? :) .NET meg a Java sem a nyelv miatt lassú, hanem a sok-sok osztálykönyvtár miatt, ami miatt gyors lesz a fejlesztés. Na meg az egyéb kényelmi dolgok miatt (tisztább syntax, új nyelvi featurek, sok egyéb menedzselt dolog, amit levesz a válladról a VM, ami alatta van, stb.)

TCH írta/wrote:
ha virtuális memóriaáthelyezéssel csinálja a .NET, akkor az C-ben is megy, lévén az nem szoftveres, hanem az MMU műve.

Tévedsz. A virtuális memória kezelésében a CPU csak hardveres támogatást nyújt, de az operációs rendszer is részt vesz benne. Ld. a swapolás megvalósítása szoftveres. Egyébként igen, a C is csinálhat ilyen átrendezgetéseket, csak épp nem a háttérben egy külön szálon, hanem egy szálon, mikor malloc()-olsz. Másrészt a virtuális címtér (amit a programodban látsz) és a fizikai címtér (amit a programodból nemigazán látsz, csak OS szinten) az eléggé két különböző dolog.

TCH írta/wrote:
Pl. a mostanság kurwára divatos MVC modell is 30 éves, csak valami hülye kitalálta, hogy ez valami nagyon új dolog és ezért nagyon modern, meg nagyon menő.

Egyik patternre sem mondtam, hogy mai találmány lenne (A Design patterns című könyv pl. 94-es és az is összefoglalni igyekezett a patterneket), csupán weben jött be, mint új fogalom, mert rájöttek, hogy ott is csak kellene valami rendszer a káoszba. De megjegyzem, az MVC, vagy az MVVM, meg a DIC, sőt még egy kósza abstract factory sem arra szolgál, hogy gyorsabb legyen a szoftvered, hanem arra, hogy átláthatóbb és rugalmasan bővíthetőbb. Meg hogy ne egy mindent keresztül-kasul hivogató cucc legyen a szoftver.

TCH írta/wrote:
Akár SNES-en is futhatna egy ilyen játék, csak meg kéne írni.

Írjad, van rá három napod.

TCH írta/wrote:
Negyed évszázaddal ezelőtt is komplett sorozatokat rendereltek le 3D-ben.
Ehhez képest ma maximum nagyobb lett a felbontás és esetleg kevésbé szögletes a mozgás, mert gyorsabban renderelnek le több fázist.

Miért, mit vártál? Több CPU idő -> nagyobb, szebb, részletesebb grafika. Na meg programozható pixel/vertex/texture/uniform shaderek.

Mellesleg az egész 3D grafikás mizériának a "mellékterméke" a GPGPU, amivel viszont párhuzamosíott matekolást nagyon durván jól lehet csinálni.

TCH írta/wrote:
"gotokra és pointerekre fordul az egész", hogy saxust parafrazáljam. :P

Uhum. És csinálja a fordító meg ;) A példakódod meg nagyon jól mutatja, hogy nem tudod, hogy mire jó az OOP.

kemi írta/wrote:
Az meg, hogy a compiler optimalizál helyetted, sajnos oda vezet, hogy képzett programozók helyett "betanított munkásokat" alkalmaznak, ami mégjobban a szofterek elhízásához vezet.

Azzal egyetértek, hogy túl sok a kontár. Viszont valahol pozitívnak tartom, hogy kevesebb időt kell bizonyos technikai dolgokra fecsérelni és több marad a konkrét feladatra. És igen, ebbe beletartozik az is, hogy hol milyen algoritmus, milyen adatstruktúrával, stb. Probléma az, hogy ezek használatához (főleg, ha az ember jól akarja csinálni) ugyanúgy kell tudás, ráadásul OOP-ben jól tervezni nehéz. Ezt mindenki elismeri.

TCH írta/wrote:
Imperatív módon is meg lehet írni a modult

Ácsi, a Java meg a C# nem erlang, meg lisp, imperatív az is ;) Csak az OOP itt segít pl. azzal, hogy nem szükséges ismerned még az osztályt sem, bőven elég az interface-ját. Amikor egy modulból meg akarsz hívni egy másikat, pl. egy DIC-ből* elkérsz egy adott interface-jű objectet és azon keresztül birizgálod. Így a modul a háttérben teljesen jól cserélhető, önállóan egységtesztelhető, stb.

* A DIC is egy érdekes állatfaj és vannak hátrányai, de vannak dolgok, amire pl. jó. Ez pl. egy ilyen.

C way ezzel szemben pl. az lehetne, hogy fogsz egy függvénypointert és/vagy egy structot függvénypointerekkel és azon keresztül mókolsz. Ilyen pl. egy drivernek az interface-ja valamelyik oprendszerben. (Talán FreeBSD, nem emlékszem már.). Szvsz, akkor már inkább legyen nyelvi feature, biztosabb, hogy a fordító betartat dolgokat.