Gartner: 2008-ig felesleges a Vista
Oldal 1 / 3Következő →
Jelentkezz be a hozzászóláshoz.
#101
😊 Marketing nélkül nem megy a dolog, de én a marketing alatt nem tisztára a reklámot (vagyis advertizingot értem), na de legyen igazad, habár akárhogy is nézed, a memóriakapacitás mindég gyorsabban fejlõdött mint a CPU teljesítmény, és ez a jövõben csak fokozódni látszik, tehát marketing ide vagy oda, szerintem jobban kell odafigyelni a kód sebességére mint a memóriaigényre. És aki programozik az tudja, hogy a kettõ alapjában nem fér össze, ha akarsz gyorsabb kódót akkor általában nem tudod a memóriaigényt is optimizálni, persze nem minden alkalommal de legtöbbször.
Ami pedig a 10-évvel ezelõtti alkalmazásokat illeti, ha összehasonlítjuk õket a maiakkal akkor nagyon nagy a változás, funkcionálissan is de sokszor sebességben is, gondold csak el mire volt képes egy 3D Studio 4-es vagy most a MAX 8-as... persze az igaz, hogy az OO kód ezt a sebességi különbséget egy picit leszûkítette, de ha nem lett volna az OO akkor a mai komplexitású szoftver sem lenne, mert egyszerûen tiszta C-ben vagy ASM-ben egy MAX 8-ast lehetetlen megírni, elméletileg persze lehetséges, de nem lenne az a csapat aki ezt ki tudná hozni és még ha ebben is tévednék, akkor nem lenne az a csapat aki azt ki tudná hozni elfogadható idõn belül. Tehát minden technológiának megvannak az elõnyei és hátrányai, de legtöbbször éppen a lehetõ legjobban csináljuk, elméletben ugyan nem, de gyakorlatban sokszor lehetetlen kísérni az elméletet.
Ami pedig a 10-évvel ezelõtti alkalmazásokat illeti, ha összehasonlítjuk õket a maiakkal akkor nagyon nagy a változás, funkcionálissan is de sokszor sebességben is, gondold csak el mire volt képes egy 3D Studio 4-es vagy most a MAX 8-as... persze az igaz, hogy az OO kód ezt a sebességi különbséget egy picit leszûkítette, de ha nem lett volna az OO akkor a mai komplexitású szoftver sem lenne, mert egyszerûen tiszta C-ben vagy ASM-ben egy MAX 8-ast lehetetlen megírni, elméletileg persze lehetséges, de nem lenne az a csapat aki ezt ki tudná hozni és még ha ebben is tévednék, akkor nem lenne az a csapat aki azt ki tudná hozni elfogadható idõn belül. Tehát minden technológiának megvannak az elõnyei és hátrányai, de legtöbbször éppen a lehetõ legjobban csináljuk, elméletben ugyan nem, de gyakorlatban sokszor lehetetlen kísérni az elméletet.
Intel.DZ77RE-75K.Core.i7-3770K.32GB.RAM.360GB.RAID.SDD.8TB.RAID.HDD.GTX660Ti.Dual.NEC.Windows.10.Enterprise Apple.Mac.mini.Core.i7-3615QM.16GB.RAM.1TB.HDD.OS.X.El.Capitan
#100
Ebben igazad van.
Itt vagyunk mostmár 4GHz fele tartó procikkal, meg 10x annyi RAM-al, mint 10 éve, és az alkalmazások közel sem futnak gyorsabban, mint 10 éve.
És annyi funkcionális bõvülés nem volt.
Itt vagyunk mostmár 4GHz fele tartó procikkal, meg 10x annyi RAM-al, mint 10 éve, és az alkalmazások közel sem futnak gyorsabban, mint 10 éve.
És annyi funkcionális bõvülés nem volt.
\"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard\" - John F. Kennedy
#99
és mennyire nincs igazad
1. szted ki akarná megfizetni azt az 15000 ember egész napos munkáját?
2. egyáltalán nem igénye ez a felhasználónak. az az érdeke, h funkcionálisan használható legyen. mutass már nekem valamit a világban, ami tökéletes és sosincs vele gond. ezzel a felfogással biztos autód sincs és buszra se szoktál szállni, meg repülõn sem utazol. pedig a hiba bekövetkeztének esélye ugyan annyi (pl kocsinál), csak a következmények súlyosabbak. ennek ellenére használják az emberek.
nemtom az sw-nek mér kéne teljesen tökéletesnek lenni. tudod egyáltalán, h az intel 4x86-os alaplapja volt az utcsó hw amit teljeskörûen leteszteltek?
nem is tudom minek eröltetem magam. egyértelmû, h egyáltalán nem vagy képben és még hajlandóságot sem mutatasz az érvek elfogadására. csak ugyan azt a bullshitet szajkózod.
1. szted ki akarná megfizetni azt az 15000 ember egész napos munkáját?
2. egyáltalán nem igénye ez a felhasználónak. az az érdeke, h funkcionálisan használható legyen. mutass már nekem valamit a világban, ami tökéletes és sosincs vele gond. ezzel a felfogással biztos autód sincs és buszra se szoktál szállni, meg repülõn sem utazol. pedig a hiba bekövetkeztének esélye ugyan annyi (pl kocsinál), csak a következmények súlyosabbak. ennek ellenére használják az emberek.
nemtom az sw-nek mér kéne teljesen tökéletesnek lenni. tudod egyáltalán, h az intel 4x86-os alaplapja volt az utcsó hw amit teljeskörûen leteszteltek?
nem is tudom minek eröltetem magam. egyértelmû, h egyáltalán nem vagy képben és még hajlandóságot sem mutatasz az érvek elfogadására. csak ugyan azt a bullshitet szajkózod.
#98
"Pl. 2-3 év múlva nem lesz probléma (aprópénz lesz) 4 GB RAM-ot rakni a gépbe, am a mai átlag 8 szorossa lesz, de alig ha hiszem hogy addigra a CPU a mai átlag 2-3 szorossa is lenne."
Na ez megint egy marketing duma, már bocs 😊
Véletlenül nem marketing szakember vagy?
Mert ez olyan amit mondassz, hogy figyelj, vedd meg a Z.X.C autót ami ugyan aszfalton csak 20-al megy, de 2-3 év múlva mindenhol e-aszfalt lesz, amin fog tudni menni 200-al is.
Tehát a jelenbe nem elõnyös, de a jövõbe sem, mert azt feltételezed hogy a fejlõdés megáll.
De nem áll meg, 2-3 év és megint itt egy új MS oprendszer egy új C%%%%++++ ami még 2x olyan lassú lesz 2x annyi erõforrást zabál (persze a programfejlesztés fele annyi ideig tart benne, ezért a programozók isteníteni fogják), tehát ha ugyanúgy rábeszéled a felhasználót hogy vegye meg, akkor megint csak lassan fog a gépén futni az alkalmazás, és így tovább örökkön-örökké, ergó sosem fog a felhasználó gépén olyan alkalmazás futni, amely azon megfelelõ sebességgel és nem a rendszert agyonterhelve mûködik. Tehát megint a felhasználó jár rosszul.
Na ez megint egy marketing duma, már bocs 😊
Véletlenül nem marketing szakember vagy?
Mert ez olyan amit mondassz, hogy figyelj, vedd meg a Z.X.C autót ami ugyan aszfalton csak 20-al megy, de 2-3 év múlva mindenhol e-aszfalt lesz, amin fog tudni menni 200-al is.
Tehát a jelenbe nem elõnyös, de a jövõbe sem, mert azt feltételezed hogy a fejlõdés megáll.
De nem áll meg, 2-3 év és megint itt egy új MS oprendszer egy új C%%%%++++ ami még 2x olyan lassú lesz 2x annyi erõforrást zabál (persze a programfejlesztés fele annyi ideig tart benne, ezért a programozók isteníteni fogják), tehát ha ugyanúgy rábeszéled a felhasználót hogy vegye meg, akkor megint csak lassan fog a gépén futni az alkalmazás, és így tovább örökkön-örökké, ergó sosem fog a felhasználó gépén olyan alkalmazás futni, amely azon megfelelõ sebességgel és nem a rendszert agyonterhelve mûködik. Tehát megint a felhasználó jár rosszul.
#97
Neked meg az a bajod hogy végletesen be vagy szûkülve, azt fel kell fogni, hogy a felhasználót kurvára nem érdekli hogy 10-en dolgoztak a programján vagy 15000-en, hogy napi 5 órában vagy 24-ben, elvárja hogy a korszerûnek mondható hardverén a programok normális sebességgel és hibamentesen fussanak.
#96
bármi változtatás csak jót tett volna a javanak 😄
ha sikerül ms-nek a cucc, akkor most nem örülhetnénk a .Net-ek. szal sun elérte, h erõs támogató helyett kapott egy mindent elsöprõ ellenfelet...
ugyan már, ms hova törekedett volna, amikor még csak 1 volt a sok kicsi sw cég között? akkor nem volt mit megtartania. egyszerûen kielégítette a piac igényét, ezért elterjedt.
ha sikerül ms-nek a cucc, akkor most nem örülhetnénk a .Net-ek. szal sun elérte, h erõs támogató helyett kapott egy mindent elsöprõ ellenfelet...
ugyan már, ms hova törekedett volna, amikor még csak 1 volt a sok kicsi sw cég között? akkor nem volt mit megtartania. egyszerûen kielégítette a piac igényét, ezért elterjedt.
#95
Bár nyilván figyelembe vette a piaci igényeket is, de az MS szándékosan törekedett mindenféle eszközzel elérni a monopóliumot és megtartani azt. Lásd a Java megváltoztatására tett nem éppen dicsõ kisérlete.
#94
#92 ha ze alatt azt érted, h nem programozási szentírásokat követett, hanem a piac valós igényeit próbálta kielégíteni akkor igazad van. én ezt inkább pozitívumnak veszem.
#93 így igaz.
#91 félelmetes, mennyire nem vagy képben és ennek ellenére nem vagy hajlandó elfogadni a tapasztaltabbak állítását. tuti, h még 1 valós projektben sem vettél részt.
#93 így igaz.
#91 félelmetes, mennyire nem vagy képben és ennek ellenére nem vagy hajlandó elfogadni a tapasztaltabbak állítását. tuti, h még 1 valós projektben sem vettél részt.
#93
Inkább vesz sok vásárló újabb hardvert és használja az új szoftert, mint várjon még egy évet az optimalizáltabb (és emiatt drágább) szoftverre.
#92
"a Microsoftra, mert aligha volt nekik a legjobb kódjuk a világon és mégis a legsikeresebb programokat mondhatják magukénak, mindez éppen azért mert használható kódot állítottak elõ és az optimizálás meg a többi dolog csak másodlagos volt számukra."
Az MS azért lett sikeres, mert az üzleti oldalára koncentrált a szoftverfejlesztésnek, nem a technikai oldalára. Nem úgy ért el sikereket, hogy életképesebb szoftvert indított a versenyben, hanem úgy, hogy a versenyt alakította a maga termékéhez <#nyes>
Az MS azért lett sikeres, mert az üzleti oldalára koncentrált a szoftverfejlesztésnek, nem a technikai oldalára. Nem úgy ért el sikereket, hogy életképesebb szoftvert indított a versenyben, hanem úgy, hogy a versenyt alakította a maga termékéhez <#nyes>
#91
Továbbra is az a véleményem hogy irreális hogy minden attól hangos hogy gyorsabb proci gyorsabb memória gyorsabb hardver...azzal senki se törõdik hogy a programozók lustasága/vagy a fejlesztést vezénylõ cég pénzéhsége miatt egyre lassabb programok jelennek meg.
Tehát a hardver hiába gyorsul, ha a szoftver "költségkímélési szempontok" miatt lassabb lesz.
Akkor legalább a korrektség miatt tájékoztatni kellene az átlagvásárlót, hogy azért kell kétévente új gépet vennie, mert a szoftvergyártó cégek minnél nagyobb haszonkulccsal akarnak dolgozni.
Egyébként a sebesség és erõforrásigény egy dolog, ma inkább a gond azzal van, hogy a szemét termékekhez hasonlóan szemét programok jelennek meg. Persze, a fejlesztõ mondhatja, hogy azért programoztam c#-ben mert basztam megtanulni programozni és szoros volt a határidõ, de
1. megtanulhatott volna programozni
2. szólni kell hogy a határidõ nem tartható, vagy a végeredmény szemét lesz.
Pont a Vistáról lehetett olyan cikket olvasni, hogy azért csúszott fél évet mert az MS vezetõje nem hitte el az egyik vezetõ programozója állítását, melyszerint az egész Vista fejlesztés úgy szar ahogy van, újra kell írni nulláról.
Tehát a határidõre való hivatkozás nem éppen jó védekezés...
Korábban írta valaki az AMS-et, de én nem említettem az ASM programozást.
Gyakorlatilag minden program elõbb utóbb AMS-ben (gépi kód szavasítva) fut, hiszen a proci azt érti, persze nem mindegy hogy ezt a fordító állítja elõ, vagy pedig maga az ember.
Szerintem direkt ASM-ben való programozás specifikus esetekben lehet szükséges, pl. sebességkritikus részeknél.
Nade ez nem azt jelenti hogy az egész alkalmazást ASM-ben kell írni (programozók ilyet nem gondolnának), hanem csak azt az adott részt (függvényt/szubritint/eljárást...) tehát akár a program kódméretének ezred vagy tízezred részét.
Tehát a hardver hiába gyorsul, ha a szoftver "költségkímélési szempontok" miatt lassabb lesz.
Akkor legalább a korrektség miatt tájékoztatni kellene az átlagvásárlót, hogy azért kell kétévente új gépet vennie, mert a szoftvergyártó cégek minnél nagyobb haszonkulccsal akarnak dolgozni.
Egyébként a sebesség és erõforrásigény egy dolog, ma inkább a gond azzal van, hogy a szemét termékekhez hasonlóan szemét programok jelennek meg. Persze, a fejlesztõ mondhatja, hogy azért programoztam c#-ben mert basztam megtanulni programozni és szoros volt a határidõ, de
1. megtanulhatott volna programozni
2. szólni kell hogy a határidõ nem tartható, vagy a végeredmény szemét lesz.
Pont a Vistáról lehetett olyan cikket olvasni, hogy azért csúszott fél évet mert az MS vezetõje nem hitte el az egyik vezetõ programozója állítását, melyszerint az egész Vista fejlesztés úgy szar ahogy van, újra kell írni nulláról.
Tehát a határidõre való hivatkozás nem éppen jó védekezés...
Korábban írta valaki az AMS-et, de én nem említettem az ASM programozást.
Gyakorlatilag minden program elõbb utóbb AMS-ben (gépi kód szavasítva) fut, hiszen a proci azt érti, persze nem mindegy hogy ezt a fordító állítja elõ, vagy pedig maga az ember.
Szerintem direkt ASM-ben való programozás specifikus esetekben lehet szükséges, pl. sebességkritikus részeknél.
Nade ez nem azt jelenti hogy az egész alkalmazást ASM-ben kell írni (programozók ilyet nem gondolnának), hanem csak azt az adott részt (függvényt/szubritint/eljárást...) tehát akár a program kódméretének ezred vagy tízezred részét.
#90
"de megnezem azt a programot, aminek az adatbazisat elore szejjel optimalizaljak. Szerintem sokkal gyakoribb, hogy utolag kezdenek el optimalizalni"
Utólag már nem lehet akármit megcsinálni. Az optimalizálás legeslegfontosabb része éppen a jó tervezés (nem csak adatbázisoknál). Az elsõdleges kérdés, hogy milyen adatokat kell egyáltalán tárolni, aztán jön az adatstruktúra és a munkafolyamatok felépítése, és végül a konkrét lekérdezések optimalizálása. Csak az utolsó fázist lehet utólag is könnyen elvégezni.
"mivel olyan teszt kornyezetet nehez csinalni, mint egy egyeves eles kornyezet."
Általában nem nulláról kezdik. Ma már legtöbbször van egy régebbi rendszer, ami alapján a fontosabb üzemi paraméterek ismertek. Ha meg még nincs semmilyen korábbi adatbázis a cégnél, akkor sokkal-sokkal több idõt kell a tervezésre fordítani. Rettentõ költséges dolog utólag újratervezni az egész rendszert .
Utólag már nem lehet akármit megcsinálni. Az optimalizálás legeslegfontosabb része éppen a jó tervezés (nem csak adatbázisoknál). Az elsõdleges kérdés, hogy milyen adatokat kell egyáltalán tárolni, aztán jön az adatstruktúra és a munkafolyamatok felépítése, és végül a konkrét lekérdezések optimalizálása. Csak az utolsó fázist lehet utólag is könnyen elvégezni.
"mivel olyan teszt kornyezetet nehez csinalni, mint egy egyeves eles kornyezet."
Általában nem nulláról kezdik. Ma már legtöbbször van egy régebbi rendszer, ami alapján a fontosabb üzemi paraméterek ismertek. Ha meg még nincs semmilyen korábbi adatbázis a cégnél, akkor sokkal-sokkal több idõt kell a tervezésre fordítani. Rettentõ költséges dolog utólag újratervezni az egész rendszert .
#89
Na megérkeztünk az én területemre 😊 SQL.
Az adabázis optimizálás vagy inkább nevezném tuningolás, egy extra komplex téma. És ha apró bázisról van szó akkor általában nem foglalkoznak vele, ha közepes bázisról van szó akkor már nem árt odafigyelni, míg massziv bázisok esetében a legfontosabb dolog. De minden esetben az SQL tuningolás egy komolyan kezelt vállalkozás kell, hogy legyen. Az adatbázis teljesítményét lehetetlen egyoldalúan növelni, vagyis szoros együttmûködésre van szükség a fejlesztõk az adatbázis adminisztrátorok az infrastruktúra vagyis rendszermérnökök (ide beleértem a rendszergazdákat is és a hálózati mérnököket is). Elõször is egy adatbázis teljesítménye nagyon függ az adatok struktúrájától, a normalizáció fokozatától (van ahol a denormalizáció gyorsít), az indexeléstõl, a hálozati forgalomtól (ez különössen érvényes amikor néhányezer kliens konkurensen lóg a rendszeren), stb. Tehát optimizálni az SQL kódot a többi nélkül nem nagyon érdemes, habár alapszabály, hogy oda kell figyelni a joins-okra és a subquery-kre, meg az ORDER BY-ra. És sokszor segít még az átlagos user pattern is, vagyis egyfajta Paretó diagram ami arról szól, hogy melyik adatcsoportot használják jobban, ezekre különössen odakell figyelni a tuningoláskor. Na, hogy ne dumáljak reggelig, az adatbázisok tudományának fele éppen a tuningolás, és ez nagyrendszerek esetében extra fontos, mert néhány extra CPU vagy extra szerver az évi költségeket képes jócskán megterhelni, mint licensz úgy karbantartási és energiaszámlákon keresztül, tehát ez egy olyan terület ahol az optimizáció nem elenyészhetõ, bár amikor nagyobb bázisokról beszélünk.
Az adabázis optimizálás vagy inkább nevezném tuningolás, egy extra komplex téma. És ha apró bázisról van szó akkor általában nem foglalkoznak vele, ha közepes bázisról van szó akkor már nem árt odafigyelni, míg massziv bázisok esetében a legfontosabb dolog. De minden esetben az SQL tuningolás egy komolyan kezelt vállalkozás kell, hogy legyen. Az adatbázis teljesítményét lehetetlen egyoldalúan növelni, vagyis szoros együttmûködésre van szükség a fejlesztõk az adatbázis adminisztrátorok az infrastruktúra vagyis rendszermérnökök (ide beleértem a rendszergazdákat is és a hálózati mérnököket is). Elõször is egy adatbázis teljesítménye nagyon függ az adatok struktúrájától, a normalizáció fokozatától (van ahol a denormalizáció gyorsít), az indexeléstõl, a hálozati forgalomtól (ez különössen érvényes amikor néhányezer kliens konkurensen lóg a rendszeren), stb. Tehát optimizálni az SQL kódot a többi nélkül nem nagyon érdemes, habár alapszabály, hogy oda kell figyelni a joins-okra és a subquery-kre, meg az ORDER BY-ra. És sokszor segít még az átlagos user pattern is, vagyis egyfajta Paretó diagram ami arról szól, hogy melyik adatcsoportot használják jobban, ezekre különössen odakell figyelni a tuningoláskor. Na, hogy ne dumáljak reggelig, az adatbázisok tudományának fele éppen a tuningolás, és ez nagyrendszerek esetében extra fontos, mert néhány extra CPU vagy extra szerver az évi költségeket képes jócskán megterhelni, mint licensz úgy karbantartási és energiaszámlákon keresztül, tehát ez egy olyan terület ahol az optimizáció nem elenyészhetõ, bár amikor nagyobb bázisokról beszélünk.
Intel.DZ77RE-75K.Core.i7-3770K.32GB.RAM.360GB.RAID.SDD.8TB.RAID.HDD.GTX660Ti.Dual.NEC.Windows.10.Enterprise Apple.Mac.mini.Core.i7-3615QM.16GB.RAM.1TB.HDD.OS.X.El.Capitan
#88
ezt egy fel pillanatig se kerdojelezem meg, de megnezem azt a programot, aminek az adatbazisat elore szejjel optimalizaljak. Szerintem sokkal gyakoribb, hogy utolag kezdenek el optimalizalni, mivel olyan teszt kornyezetet nehez csinalni, mint egy egyeves eles kornyezet. Akkor aztan johet az oracle es kianalizalhatja magat es majd jol megmondja a statisztikai alapjan, hogy mi a szar meg mi a jo. Aztan ebbol elindulva - meg a felhasznalok epito otleteibol (lassu ez a szar) - mar lehet is optimalizalni. (szerintem)
\"Kinézet hajhászó átlagfelhasználó\" by GyP
#87
a ms-részt hányszor próbáltam elmagyarázni az ilyen sebesség mindenek felett linux fan vagyok-nak, de nem képesek megérteni...
#86
egyelõre. de ha megfigyeled akkor láthatod, h azt is írtam, amint elterjednek a .netes programok, onnantól kezdve minden rendzser fejlesztõjének érdeke lesz implementálnija a frameworköt. és ebben semmi nem akadájozza meg, mivel teljesen nyílt a dolog.
azon az osen, amin nincs framework, arra nem lehet .net-es progit írni...
azon az osen, amin nincs framework, arra nem lehet .net-es progit írni...
#85
jaja, jó meglátás😊
#84
Egyébként az nagy baromság, hogy a Vista csak biztonsági frissítésekeket tartalmaz.
Nem is egyszer volt róla cikk itt az SG-n is, hogy teljesen újragondolták az egész platformot, majd félúton mégegyszer, amikor kiderült, hogy a HW nem a várt ütemben fejlõdik. És nem csupán a biztonságról van szó, sok más is javult (pl. memória kezelés).
De az pláne vicces, hogy évekig a biztonság miatt fikázták az MS-t, és most hogy az új win legfõbb tulajsonsága a nagyobb biztonság, már azt mondják, hogy jó az XP is.
Meg a win vs. linux vitákban is megy a fikázás, hogy milyen szar a win, aztán meg most kiderül, hogy semmi baj az xp-vel, nem is kell a vista.
Nem is egyszer volt róla cikk itt az SG-n is, hogy teljesen újragondolták az egész platformot, majd félúton mégegyszer, amikor kiderült, hogy a HW nem a várt ütemben fejlõdik. És nem csupán a biztonságról van szó, sok más is javult (pl. memória kezelés).
De az pláne vicces, hogy évekig a biztonság miatt fikázták az MS-t, és most hogy az új win legfõbb tulajsonsága a nagyobb biztonság, már azt mondják, hogy jó az XP is.
Meg a win vs. linux vitákban is megy a fikázás, hogy milyen szar a win, aztán meg most kiderül, hogy semmi baj az xp-vel, nem is kell a vista.
#83
"hogy valami 1 vagy 10 millisec alatt fut az annyira tok mindegy egy adatbazis alapu uzleti szoftvernel, hogy csak na."
Ott meg az SQL utasításokat kell optimalizálni. Az se könnyebb.
Ott meg az SQL utasításokat kell optimalizálni. Az se könnyebb.
#82
nem ertek veled teljesen egyet. mert persze hulyeseget nem fogsz leirni kodban, de peldaul meg veletlenul sem irtam volna 1.0-as frameworkon for ciklust foreach helyett pedig megmondtak, hogy sokkal lassab. es 1.1-ben ki is javitottak. aztan meg szamtalan ilyen van, pl most a 2.0-rol meseltek sokat a bemutato konferencian, hogy mi minden gyorsult. szoval en arra gondoltam, amikor azt irtam amit irtam, hogy a franc fog allandoan mindent IL kodra foditva leellenorizni, hogy ertelmesen foditja-e vagy sem.
Nezz meg egy switchet, hogy milyen lesz IL kodban 😊
altalaban ervenyes, hogy real time dolgokat nem irnak ilyen nyelven -bar irtam mar valos ideju mozgaserzekelot. persze unsafe blokkban pointerekkel. ott erdemes pocsmorogni a sebesseggel, meg meregetni, de az, hogy valami 1 vagy 10 millisec alatt fut az annyira tok mindegy egy adatbazis alapu uzleti szoftvernel, hogy csak na.
Nezz meg egy switchet, hogy milyen lesz IL kodban 😊
altalaban ervenyes, hogy real time dolgokat nem irnak ilyen nyelven -bar irtam mar valos ideju mozgaserzekelot. persze unsafe blokkban pointerekkel. ott erdemes pocsmorogni a sebesseggel, meg meregetni, de az, hogy valami 1 vagy 10 millisec alatt fut az annyira tok mindegy egy adatbazis alapu uzleti szoftvernel, hogy csak na.
\"Kinézet hajhászó átlagfelhasználó\" by GyP
#81
hmm? ASM-ben sokkal könnyebb rossz kódot írni, mert ott nincs aki megakadályozzon, tehát lefoglalok a memóriából, és elfelejtem felszabadítani, akkor ez rossz kód, szintén beletömök egy long-ot értéket egy short-ba és ez is rossz kód, a biztonságról ne is beszéljünk, de még sorolhatnám, tehát ASM esetében a programozón múlik minden, mígy C-ben már nem annyira, habár ott is egy pici pointer aritmetika ha nem figyelünk oda zûrzavart okoz, C++ ettõl még egy picit többet segít a programozónak, C# meg már egész jó barátunk lesz. Szóval amit lejebb leírtam az áll, és oda kell figyelni, ismerni kell az architektúrát akármennyire is abstrakt szinten dolgozunk, de ha ASM-ben nyomjuk a dolgokat akkor sokkal de sokkal jobban oda kell figyelni, mert ott minden sorocska töllûnk függ, ellentétben a magasabb nyelvekkel ahol a könyvtárakban levõ funkciók, osztályok stb. kódja már elég jól van optimizálva, és széleskörûen van használva, ezért sokkal magasabb minõségre és biztonságosabb kódra támaszkodhatunk. Szóval ASM szerintem ma csak oda kell, ahol tényleg a teljesítmény a legfontosabb, vagyis olyan rutinok optimizálására amelyek sokszor futnak ezáltal sok ciklust és vagy memóriát takarítva meg. De a valóságban az az igazság, hogy nagyon kevés a jó kód, és már örülni szoktam, ha a kód átlagon felüli, és ha ehhez hasonlítanánk egy tökre csiszolt kódot akkor sirva fakadnánk, de a gyors fejlõdés és még gyorsabb elavúlás ehhez nem ad sem idõt sem szükséget. Ma egyszerûen sokkal fontosabb a funkcionális kód, aki nem hiszi, gondoljon a Microsoftra, mert aligha volt nekik a legjobb kódjuk a világon és mégis a legsikeresebb programokat mondhatják magukénak, mindez éppen azért mert használható kódot állítottak elõ és az optimizálás meg a többi dolog csak másodlagos volt számukra. Tehát fontos a dolgokat meghatározott keretek közé rakni és úgy figyelni, ha csak egy vagy néhány dologra összpontosítunk akkor jobb ha nem is csináljuk, mert nem fog az ég világon semmit sem érni.
Különben jól elmásztunk a Vistá-tól... vagy a Gartnertõl... 😊
Különben jól elmásztunk a Vistá-tól... vagy a Gartnertõl... 😊
Intel.DZ77RE-75K.Core.i7-3770K.32GB.RAM.360GB.RAID.SDD.8TB.RAID.HDD.GTX660Ti.Dual.NEC.Windows.10.Enterprise Apple.Mac.mini.Core.i7-3615QM.16GB.RAM.1TB.HDD.OS.X.El.Capitan
#80
"A változások legnagyobb része ugyanis olyan biztonsági frissítésekbõl áll, amelyek különbözõ forrásokból jelenleg is hozzáférhetõk."
tovább:<#nevetes2>
"Az otthoni felhasználóknak azonban mindenképpen érdemes lesz belevágniuk a cserébe, már csak a nagyobb biztonság miatt is." De most akkor mirõõõl beszélünk?<#idiota>
Emiatt nem fogok 40rugót(vagy többet)kiadni. Nehogymá' a 'biztonság' miatt vegyek új csili-vili winfost<#mf1><#banplz>
Mellesleg ezt az ablak elfordítgatósdit már egy sw program (is) tudja....
tovább:<#nevetes2>
"Az otthoni felhasználóknak azonban mindenképpen érdemes lesz belevágniuk a cserébe, már csak a nagyobb biztonság miatt is." De most akkor mirõõõl beszélünk?<#idiota>
Emiatt nem fogok 40rugót(vagy többet)kiadni. Nehogymá' a 'biztonság' miatt vegyek új csili-vili winfost<#mf1><#banplz>
Mellesleg ezt az ablak elfordítgatósdit már egy sw program (is) tudja....
#79
Persze, csak arról van szó, hogy pl. ASM-ben egy fokkal nehezebb nagyon rossz kódot írni (persze vannak kivételek), mint C-ben, és talán méginkább igaz ez a C++-ra, C#-ra, Javára, stb. Szal a programozón is sok múlik. De a legtöbben mégsem figyelnek oda. (Lásd pl. amit BlackRose írt a #78-ban.)
#78
Egyetértünk 😊
Különben egyértelmû, hogy a .NET a Windows világban sokkal jobb mint a Java, és én a Java-t csak a non-Windows világban támogatom, azért mert ott nincs .NET, a Mono ugyan fejlõdik, de legyünk komolyak, jelenleg nem igen fejleszt rajta senki sem komolyabb üzleti alkalmazást.
A másik dolog, pedig ha már a kód hordozhatóságának és optimizálásának a kombinációja a fõ téma, akkor az igazság ott van, hogy habár a fordítók verzióról verzióra jobbak, még mindég nem lehet tényleg optimális kódot írni, ha nem célozzuk meg az adott architektúrát, processzorcsaládot. Pl. nézzük a követlezõ peldát - na itt most C/C++ és ASM fánok mind meglesznek elégedve 😊
int i;
i = i / 4;
a fordtító a következõ kódot generálja...
mov eax, i
cdq
and edx, 3
add eax, edx
sar eax, 2
mov i, eax
na most tegyük ugyanezt a következõ képpen...
unsigned int i;
i = i / 4;
a fordító megtakarít egy csomó ciklust...
shr i, 2
tehát ismerve az x86 architektúrát, amikor lehet használom az unsigned tipust, másik architektúrákon ez lehet, hogy szintén jó lesz, de nem biztos, azokat is ismerni kell.
Na a baj ott van, hogy ha nem tudom ezt, és persze lusta vagyok gondolkodni, hogy az adott változónak csak pozitív értekei lehetnek vagy esetleg kell negatív is, akkor ezt én kihagyom és ezáltal lasabb tehát optimizátlanabb kódot írok.
Na most ide bejön a MSIL a közepébe vagy a JVM kód, és most akkor itt sok minden magától a JIT-tõl függ, na a .NET elõnye itt éppen abban rejlik, hogy a JIT x86-ra optimizálódik, míg a Java esetében biztos, hogy szintén törekszenek az optimizálásra, de mivel több architektúrán kell, hogy dolgozzon ez vagy extra idõbe kerül a Sun fejlesztõinek, vagy egyszerûen kihagyják. Na szerintem ez is hozzájárul a Java és .NET közötti teljesítménykülönbséghez. Érdekes, de ha a fenti peldát C#-ban megírjuk a fordító jó MSIL kódot generál és a JIT is ugyanezt teszi, tehát megkapjuk az optimizált gépi kódot éppen úgy mintha sima C-ben írnánk, vagy ha akarjátok ASM-ben is.
Különben egyértelmû, hogy a .NET a Windows világban sokkal jobb mint a Java, és én a Java-t csak a non-Windows világban támogatom, azért mert ott nincs .NET, a Mono ugyan fejlõdik, de legyünk komolyak, jelenleg nem igen fejleszt rajta senki sem komolyabb üzleti alkalmazást.
A másik dolog, pedig ha már a kód hordozhatóságának és optimizálásának a kombinációja a fõ téma, akkor az igazság ott van, hogy habár a fordítók verzióról verzióra jobbak, még mindég nem lehet tényleg optimális kódot írni, ha nem célozzuk meg az adott architektúrát, processzorcsaládot. Pl. nézzük a követlezõ peldát - na itt most C/C++ és ASM fánok mind meglesznek elégedve 😊
int i;
i = i / 4;
a fordtító a következõ kódot generálja...
mov eax, i
cdq
and edx, 3
add eax, edx
sar eax, 2
mov i, eax
na most tegyük ugyanezt a következõ képpen...
unsigned int i;
i = i / 4;
a fordító megtakarít egy csomó ciklust...
shr i, 2
tehát ismerve az x86 architektúrát, amikor lehet használom az unsigned tipust, másik architektúrákon ez lehet, hogy szintén jó lesz, de nem biztos, azokat is ismerni kell.
Na a baj ott van, hogy ha nem tudom ezt, és persze lusta vagyok gondolkodni, hogy az adott változónak csak pozitív értekei lehetnek vagy esetleg kell negatív is, akkor ezt én kihagyom és ezáltal lasabb tehát optimizátlanabb kódot írok.
Na most ide bejön a MSIL a közepébe vagy a JVM kód, és most akkor itt sok minden magától a JIT-tõl függ, na a .NET elõnye itt éppen abban rejlik, hogy a JIT x86-ra optimizálódik, míg a Java esetében biztos, hogy szintén törekszenek az optimizálásra, de mivel több architektúrán kell, hogy dolgozzon ez vagy extra idõbe kerül a Sun fejlesztõinek, vagy egyszerûen kihagyják. Na szerintem ez is hozzájárul a Java és .NET közötti teljesítménykülönbséghez. Érdekes, de ha a fenti peldát C#-ban megírjuk a fordító jó MSIL kódot generál és a JIT is ugyanezt teszi, tehát megkapjuk az optimizált gépi kódot éppen úgy mintha sima C-ben írnánk, vagy ha akarjátok ASM-ben is.
Intel.DZ77RE-75K.Core.i7-3770K.32GB.RAM.360GB.RAID.SDD.8TB.RAID.HDD.GTX660Ti.Dual.NEC.Windows.10.Enterprise Apple.Mac.mini.Core.i7-3615QM.16GB.RAM.1TB.HDD.OS.X.El.Capitan
#77
Pont te mondtad, hogy .net winen kívül csak linuxra van eddig 😊
\"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard\" - John F. Kennedy
#76
azért az nem teljesen mindegy, h 1x megírok 1 fájl kezelõ rutint, vagy 3x mert 3 különbözõ osre is szeretném elkészíteni...
#75
Na jó, de az ASM meg a C közt sokkal nagyobb a különbség, mint a C és a C# között.
A lényeg úgyis maga az algoritmus, azt meg semmilyen nyelv nem találja ki neked.
Az, hogy a C#-ben bevezettek néhány magasabb szintû dolgot, az csak egy dolog, ezek viszonylag kis részei a programnak, és nem azok, amik felett órákig kell rágódni. Szóval azokat a függvényeket megírod több platformra, és készen vagy.
A lényeg úgyis maga az algoritmus, azt meg semmilyen nyelv nem találja ki neked.
Az, hogy a C#-ben bevezettek néhány magasabb szintû dolgot, az csak egy dolog, ezek viszonylag kis részei a programnak, és nem azok, amik felett órákig kell rágódni. Szóval azokat a függvényeket megírod több platformra, és készen vagy.
\"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard\" - John F. Kennedy
#74
asszem kicsit elcsúsztunk, mert onnan indultunk ki, h C/C++ban optimálisabb végeredményt kapunk. nem arról volt szó, h maga a programozó hogy old meg egy metódust.
Egy genercióval elõbbi példát véve, hiába kapunk ASMben optimálisabb kódot, mégis C/C++ben programozunk (sõt C helyett is inkább C++ban), mert egy komolyabb progi (akár egy játék) 10 év és 100 fõs csapat helyett 2 év 20 fõs csapatból is megvan. Ez a C#ban mégjobban elõjön, a létrejött kód újra hasznosíthatóbbságáról (
Egy genercióval elõbbi példát véve, hiába kapunk ASMben optimálisabb kódot, mégis C/C++ben programozunk (sõt C helyett is inkább C++ban), mert egy komolyabb progi (akár egy játék) 10 év és 100 fõs csapat helyett 2 év 20 fõs csapatból is megvan. Ez a C#ban mégjobban elõjön, a létrejött kód újra hasznosíthatóbbságáról (
#73
értem én.
egyébként a kliens oldali kódnál teljesen más számít optimizációnak. nem kell azt szídni. ott a legfontosabb a forráskód mérete, aztán szünet, majd a teljesítménye. ezek a php-s dolgok is, meg olyanok, h méretüknél fogva egyáltalán nem éri meg optimizálni õket.
#70 ez is rendben, de a létrehozott objektum hiába foglal többet a memóriában, ha progrem többi része lehet semmenyit nem foglal, mert egy másik progival közösen használ (olvas!) egy memóriaterületet. ezért mondtam, h minnél több fut párhuzamosan, annál jobban elõjön.
pl: memóriafoglalás párhuzamosan futtatott programnál (egységekben)
.NetC# | JAVA
4 | 3
elindítom a köv progit:
6 | 6
kövnél:
8 | 9
10 | 12
12 | 15
14 | 18
és akkor még nem számoltam ide, h ekkora javanál már 6 JVM van betöltve.
de teljesen mind1, mert minden másban egyértelmûen jobb, tehát végeredményben .NetC# éri meg jobban.
egyébként a kliens oldali kódnál teljesen más számít optimizációnak. nem kell azt szídni. ott a legfontosabb a forráskód mérete, aztán szünet, majd a teljesítménye. ezek a php-s dolgok is, meg olyanok, h méretüknél fogva egyáltalán nem éri meg optimizálni õket.
#70 ez is rendben, de a létrehozott objektum hiába foglal többet a memóriában, ha progrem többi része lehet semmenyit nem foglal, mert egy másik progival közösen használ (olvas!) egy memóriaterületet. ezért mondtam, h minnél több fut párhuzamosan, annál jobban elõjön.
pl: memóriafoglalás párhuzamosan futtatott programnál (egységekben)
.NetC# | JAVA
4 | 3
elindítom a köv progit:
6 | 6
kövnél:
8 | 9
10 | 12
12 | 15
14 | 18
és akkor még nem számoltam ide, h ekkora javanál már 6 JVM van betöltve.
de teljesen mind1, mert minden másban egyértelmûen jobb, tehát végeredményben .NetC# éri meg jobban.
#72
Nem csak utólagos optimizálással lehet viszonylag optimális kódot készíteni, hanem átgondoltsággal, kiforrottabb programozási stílussal, jó programszervezéssel, stb. 5 perc gondolkodás többet ér, mint több óra "szívás". De milyen sokan megfeledkeznek errõl...
#71
optimalizaljon az, aki nem ismeri hatarido urat.
\"Kinézet hajhászó átlagfelhasználó\" by GyP
#70
OK, de nem erre gondoltam.
Pl. ha csinálsz egy új objektumot
blablaOsztaly blablaObjektum = new blablaOsztaly();
ez .NET-ben több memóriát zabál meg mint a Java környezetben, ha meg pl. ebbõl csinálsz egy 100.000-es array-t akkor ez akár 2-3 szor is több lehet mint a Java környezetben. De mégegyszer mondom, ugyanakkor 2x gyorsabban fogok dolgozni ugyanezekkel a nagy memóriazabáló objektumokkal mint a Javaban. Különben errõl valahol a TheServerSide.net-en vagy .com-on (egyik .NET, másik Java) lehetett olvasni, éppen a .NET 2.0-át és a Java 5-öt tették egymás ellen.
Pl. ha csinálsz egy új objektumot
blablaOsztaly blablaObjektum = new blablaOsztaly();
ez .NET-ben több memóriát zabál meg mint a Java környezetben, ha meg pl. ebbõl csinálsz egy 100.000-es array-t akkor ez akár 2-3 szor is több lehet mint a Java környezetben. De mégegyszer mondom, ugyanakkor 2x gyorsabban fogok dolgozni ugyanezekkel a nagy memóriazabáló objektumokkal mint a Javaban. Különben errõl valahol a TheServerSide.net-en vagy .com-on (egyik .NET, másik Java) lehetett olvasni, éppen a .NET 2.0-át és a Java 5-öt tették egymás ellen.
Intel.DZ77RE-75K.Core.i7-3770K.32GB.RAM.360GB.RAID.SDD.8TB.RAID.HDD.GTX660Ti.Dual.NEC.Windows.10.Enterprise Apple.Mac.mini.Core.i7-3615QM.16GB.RAM.1TB.HDD.OS.X.El.Capitan
#69
A kód optimizálása akkor fontos, ha a befektetett erõforrás és idõ megtérül azáltal, éppen úgy mint más dolgok által a listán.
De a jelenlegi szoftverfejlesztésben a kód újrahasználhatósága (komponensek fejlesztése) általában a legfontosabb. A második helyen általában a kód biztonsági oldala van vagy bár kellene, hogy legyen, harmadik a kód jó azaz bõvíthetõ szervezése van. Az optimizáció a mai memóriaözönben meg processzor teljesítményben csak ritka alkalmazások esetén fontos, persze ez nem jelenti, hogy tökhülye kódod kell írni... de mégis megvan a határ. Általában azt tapasztalom, hogy azok a fejlesztõk akik ismerik a C/C++, vagy még jobb az ASM-emet is, azok jobb és optimizáltabb kódot írnak, azok az általában újkeletû fejlesztõk akiknek a Java vagy VB, Delphi volt a tanulóplatforma vagy még roszabb, webfejlesztéssel kezdték és JScript-en, PHP-én meg HTML-en lovagolnak, azok sokkal optimizálatlanabb kódot termelnek. Persze van kivétel, de általában ez a szabály. Különben a .NET-el tényleg lehet nemnormálissan optimizálatlan kódot írni, ezért kell elõbb jól megtanulni, sokan nekiûlnek és a Hallo World után produkciós kódot írnak, de ez általában szemét kód. Nem szeretem azokat akiknek nincs legalább 6-9 hónap erõss (mindennapi néhányórás) gyakorlatuk, egy csómó könyv elolvasásával együtt. Mennyire nem szeretem õket, annyira, hogy nem dolgozok velük. Különben a fejlesztõi munkakörnyezetemben 3 emberre számíthatok akik végig csinálták az ASM-tõl a C#-ig, és kimondott szabálynak tartom, hogy Phyton, Ruby, Perl vagy valami hasonló dolog is legyen az újjukban, mert a soknyelvûség nagyon jó effektussal jár mint az optimizált kód írására, úgy a jó szervezettségre is. Mégegyszer mondom nagyon kevés függ a platformtól, inkább az emberek határozzák meg a kód minõségét.
De a jelenlegi szoftverfejlesztésben a kód újrahasználhatósága (komponensek fejlesztése) általában a legfontosabb. A második helyen általában a kód biztonsági oldala van vagy bár kellene, hogy legyen, harmadik a kód jó azaz bõvíthetõ szervezése van. Az optimizáció a mai memóriaözönben meg processzor teljesítményben csak ritka alkalmazások esetén fontos, persze ez nem jelenti, hogy tökhülye kódod kell írni... de mégis megvan a határ. Általában azt tapasztalom, hogy azok a fejlesztõk akik ismerik a C/C++, vagy még jobb az ASM-emet is, azok jobb és optimizáltabb kódot írnak, azok az általában újkeletû fejlesztõk akiknek a Java vagy VB, Delphi volt a tanulóplatforma vagy még roszabb, webfejlesztéssel kezdték és JScript-en, PHP-én meg HTML-en lovagolnak, azok sokkal optimizálatlanabb kódot termelnek. Persze van kivétel, de általában ez a szabály. Különben a .NET-el tényleg lehet nemnormálissan optimizálatlan kódot írni, ezért kell elõbb jól megtanulni, sokan nekiûlnek és a Hallo World után produkciós kódot írnak, de ez általában szemét kód. Nem szeretem azokat akiknek nincs legalább 6-9 hónap erõss (mindennapi néhányórás) gyakorlatuk, egy csómó könyv elolvasásával együtt. Mennyire nem szeretem õket, annyira, hogy nem dolgozok velük. Különben a fejlesztõi munkakörnyezetemben 3 emberre számíthatok akik végig csinálták az ASM-tõl a C#-ig, és kimondott szabálynak tartom, hogy Phyton, Ruby, Perl vagy valami hasonló dolog is legyen az újjukban, mert a soknyelvûség nagyon jó effektussal jár mint az optimizált kód írására, úgy a jó szervezettségre is. Mégegyszer mondom nagyon kevés függ a platformtól, inkább az emberek határozzák meg a kód minõségét.
Intel.DZ77RE-75K.Core.i7-3770K.32GB.RAM.360GB.RAID.SDD.8TB.RAID.HDD.GTX660Ti.Dual.NEC.Windows.10.Enterprise Apple.Mac.mini.Core.i7-3615QM.16GB.RAM.1TB.HDD.OS.X.El.Capitan
#68
"A .NET mindenben jó, kivéve egy dologban nem, ez pedig a memóriaigény. És ennek megvan az oka, mivel abstrktizál kereskedni kell két dolog között ami nem éppen fér össze, nagyon neház ilyen magasszintû abstrakt környezetben memóriatakarékosnak és gyorsnak is lenni. Ha a .NET-et és a Java környezetet hasonlítom össze, akkor a .NET jóval gyorsabb, de jóval memóriaigényesebb is. Míg a Sun valahogy a kettõ közé beült, a Microsoft inkább a teljesítményt választotta."
ez addig igaz, míg 1db futó programról beszélünk. JVM-nél ha párhuzamosan elidítasz egy másik programot is, akkor egybõl minden erõforrás igénye megduplázódik. .NetFW-nél ez egyáltalán nem így mûködik. minnél több progit futtatsz párhuzamosan, annál jobban elõjön, h a .Net a jobb.
példa: ha az elõzõ progi már betöltött egy osztály könyvtárat, akkor az újonnan indúló már ugyan azt fogja használni. JVMnél úgy tesz, mintha a másik nem is lenne. próbálkozások vannak, de egyelõre ahány JAVA progi fut, annyi JVM aktív.
és lássuk be, az elég valószínûtlen, hogy egy gépen csak 1 progit futtasson az ember.
ez addig igaz, míg 1db futó programról beszélünk. JVM-nél ha párhuzamosan elidítasz egy másik programot is, akkor egybõl minden erõforrás igénye megduplázódik. .NetFW-nél ez egyáltalán nem így mûködik. minnél több progit futtatsz párhuzamosan, annál jobban elõjön, h a .Net a jobb.
példa: ha az elõzõ progi már betöltött egy osztály könyvtárat, akkor az újonnan indúló már ugyan azt fogja használni. JVMnél úgy tesz, mintha a másik nem is lenne. próbálkozások vannak, de egyelõre ahány JAVA progi fut, annyi JVM aktív.
és lássuk be, az elég valószínûtlen, hogy egy gépen csak 1 progit futtasson az ember.
#67
az a valóság, h a kód optimalitása a sokadik szempont...
ha az lenne az elsõ, mint ahogy hiszitek, akkor még mindig asmben programoznánk.
ha az lenne az elsõ, mint ahogy hiszitek, akkor még mindig asmben programoznánk.
#66
Igen, de mégis minden más szempontból optimálisabb kódot kapsz.
És azért ez elég ritka, tegyük hozzá.
És azért ez elég ritka, tegyük hozzá.
\"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard\" - John F. Kennedy
#65
de .nettel ellentétben ennél nem lehet arra számítani, h az adott könyvtár rajta van a platformon, vagyis máris nem lehet rá építeni. az esetleges platformok könyvtárai közötti eltérésrõl nem is beszélve. már azzal is gond lehet, ha 1 fájlt el akarok menteni...
#64
Nem kell mindent tartalmaznia a programnak. Vannak multiplatform GUI-kezelõk, OpenGL és klónjai, stb.
#63
érdekes itt egy ilyen hír és még sincs flém. tök normális a vita. 100+ komment így is meglesz. mennyivel normálisabb lenne így az egész.
#62
Lehet azert annal komolyabbakra is <#vigyor0> En pl egy ideig igy fejlesztettem egy kollegaval egy mesterseges intelligencia programot, igaz a grafikus resznel bebuktuk a hordozhatosagot <#vigyor> Amugy mivel a .NET lenyeget tekintve igy mukodik, igy elmeletileg lehetseges lenne a dolog.
#61
Einstein mondta, hogy az idõ relatív, mindenkinek van elég sõt sok ideje ha jól betudja osztani. <#smile> A baj ott kezdõdik, hogy kevesen törõdnek vele... az idõ menedzment a legfontosabb dolog. És ezek nem vesznek igénybe órákat... mindõssze 20 percet. <#smile>
Motiváció? Na ezen lehetne gondolkodni... de mindenekelõtt, az ismétlés... vagyis mikor itt leírom a dolgokat akkor valójában újragondolom, tehát ismétlem (és még az ókori Romaiak mondták, hogy az ismétlés a tudás és bölcsesség annya), sõt van amikor e közben valami újra is rájövök, esetleg az itt olvasottak alapján valamit másként gondolok... tehát mi motiválja az embert a gondolkodásra? Szerintem, hogy emberibb legyen, munkámat és mindent amit csinálok úgy fogom fel mint egy szert ami egy felsõbb célért szolgál, az pedig, hogy emberibb legyek. Na most lehet, hogy nem a legjobban fejeztem ki magam, de talán érthetõ mire gondolok.
Motiváció? Na ezen lehetne gondolkodni... de mindenekelõtt, az ismétlés... vagyis mikor itt leírom a dolgokat akkor valójában újragondolom, tehát ismétlem (és még az ókori Romaiak mondták, hogy az ismétlés a tudás és bölcsesség annya), sõt van amikor e közben valami újra is rájövök, esetleg az itt olvasottak alapján valamit másként gondolok... tehát mi motiválja az embert a gondolkodásra? Szerintem, hogy emberibb legyen, munkámat és mindent amit csinálok úgy fogom fel mint egy szert ami egy felsõbb célért szolgál, az pedig, hogy emberibb legyek. Na most lehet, hogy nem a legjobban fejeztem ki magam, de talán érthetõ mire gondolok.
Intel.DZ77RE-75K.Core.i7-3770K.32GB.RAM.360GB.RAID.SDD.8TB.RAID.HDD.GTX660Ti.Dual.NEC.Windows.10.Enterprise Apple.Mac.mini.Core.i7-3615QM.16GB.RAM.1TB.HDD.OS.X.El.Capitan
#60
maximálisan egyet értek, de a fényév, az nem idõ intervallum, hanem távolság (mint a km)
#59
és mire lehet használni olyan programot, amit így írnak meg? kiírja, h "Hello World!"?
#58
De lehet, csak olyan kódot kell írni.
Persze nem multiplatforma tervezik, csak portábilisra.
Persze nem multiplatforma tervezik, csak portábilisra.
\"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard\" - John F. Kennedy
Hiába lassabb a C#, ha fényévekkel gyorsabb rajta fejleszteni. Ma se áll már neki senki asm-ben kódolni (max egyes rutinokat), mert elavul mire elkészül. Egyszerû dosos progikhoz elég volt, ma már irreális. Vegyük pl. a Vindóz Pistát: C#-ban is ennyi idõ megírni, asm-ben mikor lenne kész? 2500? Ráadásul az asm hw specifikus, hordozhatóság 0. Minden hw-re te kódolnád le külön?
A kemény munka a későbbiekben megtérül. A lustaság viszont azonnal.
#56
BlackRose te nagyon ráérhetsz ha képes vagy naponta órákat áldozni ilyen parttalan vitákra.
Egyébként szerintem sok dologban igazad van, csak nem értem mi motivál.
Egyébként szerintem sok dologban igazad van, csak nem értem mi motivál.
#55
Arról nem szabad megfeledkezni, ha a szart sokáig tartogatják(tárolják) értékes trágya lesz belõle!
#54
ah már megint ezzel jössz. egyáltalán nem mûködik 1 progrmamnál, h fogom a másik platform fordítóját és azzal készítem el a futtatható kódot. de ha még mûködne is, akkor sem lenne még a közelében sem az ilyen JVM/.Net megoldásoknak.
btw, ha jól tudom a egyelõre csak linuxra van (mono). de meglásd amint elterjednek a .Net programok minden létezõ platformra meg fog jelenni, mivel teljesen nyílt a cucc (ellentétben a JAVA-val...). a platform készítõjének érdeke lesz...
btw, ha jól tudom a egyelõre csak linuxra van (mono). de meglásd amint elterjednek a .Net programok minden létezõ platformra meg fog jelenni, mivel teljesen nyílt a cucc (ellentétben a JAVA-val...). a platform készítõjének érdeke lesz...
#53
Hehe, teccik a sakkos kép 😄
The EULA sounds like it was written by a team of lawyers who want to tell me what I can\'t do. The GPL sounds like it was written by a human being, who wants me to know what I can do.
#52
már megválaszolták elõttem. (nem mintha nem írtam volna le én is)
Oldal 1 / 3Következő →