globalmoto_kveten





Téma: OT:Instrukce AMD
 
28.12.2011 v 15:50
Mam takovej dotaz pro nejakyho programatora... Registry pro procesry Intel sou me celkem jasny (EAX,ECX,EDX,ESP,EBP,ESI,,EDI,EIP,EFLAGS), ale abych pravdu rekl tak v cecku sem novacek a jelikoz mam AMD Tak registry sou tady jiny a ja uz v tom zacinam mit bordel,pac knizka je napsana pro Intel a ekvivalenty AMD sem nejak nenasel. Ptam se,prpto,ze kdyz pres GDB zkoumam chod programu tak diky tomu,ze Reg sou jiny tak nemuzu prozkoumavat pamet.....

(reakce na) OT:Instrukce AMD

29.12.2011 v 11:08 | Nahoru | #31

Bludevil píše: Tojo, ale znám džanyho a proto se taky tak ptám, co se mu stalo



Pochopil ze na holou prdel neutahne devky, chlast ani rock&roll

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 11:17 | Nahoru | #32
dizzi> No, to si to zjednodušil snad ještě víc, než sem si dovolil já

Java není pomalá, to je prostě mýtus. Je rychlejší, než spousta běžně dostupných jazyků (včetně toho zmiňovanýho erlangu, srovnání). Navíc i nešikovnej programátor v ní napíše kvalitnější věc, než v céčku, kde může nasekat nepočítaně chyb. Jasně, že se v céčku dá napsat o maličko výkonější kód, ale za cenu výrazně většího úsilí, než by se všem líbilo. V javě nejde udělat tolik prasáren, jako v céčku (nebo už to musí někdo extra zprasit). A to, co v javě udělám na pár řádek kódu za několik minut bude člověk v assembleru psát a ladit hodiny (se stejným množstvím zkušeností).

2 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 11:22 | Nahoru | #33

todvora píše: dizzi> No, to si to zjednodušil snad ještě víc, než sem si dovolil já

Java není pomalá, to je prostě mýtus. Je rychlejší, než spousta běžně dostupných jazyků (včetně toho zmiňovanýho erlangu, srovnání). Navíc i nešikovnej programátor v ní napíše kvalitnější věc, než v céčku, kde může nasekat nepočítaně chyb. Jasně, že se v céčku dá napsat o maličko výkonější kód, ale za cenu výrazně většího úsilí, než by se všem líbilo. V javě nejde udělat tolik prasáren, jako v céčku (nebo už to musí někdo extra zprasit). A to, co v javě udělám na pár řádek kódu za několik minut bude člověk v assembleru psát a ladit hodiny (se stejným množstvím zkušeností).



Asi si cetl jiny prispevek nez jsem napsal :) Ja jsem nerek ze java je pomala, ja rek ze to prasi programatori. Nesikovny programator rozhodne kvalitnejsi vec nenapise, napise ji jen rychlejc. Typicky zbytecna alokace/pouziti kolekci, spojovani stringu a co ja vim co.

ER lang sem uved jako priklad uplne jineho pristupu, dokaze veci o kterych se jave nesni a naopak, obecne je ale asi nema smysl porovnavat...

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 11:28 | Nahoru | #34
dizzi> No, to je přesně ono. V javě vytvoříš list a nestaráš se jak je velkej (a on bude dost často jen tak malej, jak je třeba). V céčku uděláš to, že alokuješ maximum, který by se mohlo hodit (protože jsou pole děsnej vopruz, jasně, zjednodušuju). Spojování stringů si stejně překladač přepíše na StringBuilder a podobně. Programátorovo chyby prostě eliminuje. Tak, jako nebudou všechny ty ABS, ESP a ostatní zkratky lepší než profesionální závodník, ale většině odvedou skvělou práci. Navíc kód v javě bude míň náchylnej na chyby. A v důsledku mě víc trápí to, že aplikace dvakrát do tejdne spadne na nějaký přetečení pole (céčko)než to, že je o 20% pomalejší(java). A stroje sou levný, drahej je vývoj, lidi. Ostatně, proto facebook jde cestou PHP programátorů a raději se pere s jazykem, protože to vyjde výrazně levněji a efektivněji, i když je PHP děsnej bastl. Takže z mýho pohledu: věřím že assembleru nebo c napíše profesionál o maličko lepší kód, ale za to úsilí to většinou nikomu nestojí.

2 reakcí na tento příspěvek OT:Instrukce AMD

29.12.2011 v 11:41 | Nahoru | #35
K te Jave vs C++ . Pred 6-7 lety na Stredni jsme na stahoavni torrentu pouzivali Azureus (Java). Upravoval jsem i nejake drobnosti ve zdrojacich. Udelal jsem si verzi ktera cheatovala na private Torrent trackerech a dava falesne udaje o mnozstvi uploadovanych dat.

No ale k veci. Narocnost na HW byla silena (pri rychlosti stahovani treba 3 MB/s , meli jsme tam optiku). A uTorrent napsany v C++ to same zvladl s mnohem mensim vytizeni a spotrebou CPU. Na PC mi stahuju treba 2MB/S a skoro nevim ze bezi.
Asi to hlavne bude otazka algoritmu. A treba by to v Jave slo taky. Ale Eclipse vs Visual Studio taky neco podobnyho. Jsem si kvuli Eclipse musel prikoupit ram na NB kde jsem mel jen 1GB.

Naposledy editováno 29.12.2011 11:44:53

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 11:42 | Nahoru | #36
todvora>
Zkousel si to? (to spojovani tech stringu) navic ten blbej programator nebude ani vedet jaky je rozdil mezi stringbuilderem a stringbufferem
Jave taky jeste donedavna treba nesla tail recursion (coz prakticky znamena ze ti to treba zhuci na out of memory na stacku)
Kolik casu stoji to prealokovani ty kolekce nebo to kdyz blbej programator neresi v jakem case se prvky vyndavaji/pridavaji a ktera operace je rychlejsi?
V C++ jsou taky vektory, a deque a co ja vim co.

Facebook myslim tohle neresi, ti jen udrzuji to co zbastlili na zacatku :)) (a nevim teda jak levne to vyjde kdyz musi resit i vyvoj samotneho PHP :)

Ja mam Javu rad, a ano i to hloupe napovidani editorem v realnem case zacatecnikovi pomuze, ale rikat "naplacej to tam jak chces, on si to nejak prekouse" je presne ten duvod proc dnes mame 20x rychlejsi stroje, a stejne rychly software...

2 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 11:46 | Nahoru | #37

SVSkritek píše: K te Jave vs C++ . Pred 6-7 lety na Stredni jsme na stahoavni torrentu pouzivali Azureus (Java). Upravoval jsem i nejake drobnosti ve zdrojacich. A neprislo mi ze by tam byly nejake velke prasarny. I kdyz jsem teda prochazel jen cast. Udelal jsem si verzi ktera cheatovala na private Torrent trackerech a dava falesne udaje o mnozstvi uploadovanych dat.

No ale k veci. Narocnost na HW byla silena (pri rychlosti stahovani treba 3 MB/s , meli jsme tam optiku). A uTorrent napsany v C++ to same zvladl s mnohem mensim vytizeni a spotrebou CPU. Na PC mi stahuju treba 2MB/S a skoro nevim ze bezi.
Asi to hlavne bude otazka algoritmu. A treba by to v Jave slo taky. Ale Eclipse vs Visual Studio taky neco podobnyho. Jsem si kvuli Eclipse musel prikoupit ram na NB kde jsem mel jen 1GB.



V podstate jo, vsechny ty rychlostni porovnavani tech jazyku jsou pomerne irelevantni protoze (ne)spravna implementace/vyuziti vlastnosti jazyka obycejne udelaji tak velky rozdil, ze rychlost samotneho jazyka je nepodstatna.

1GB ram uz je dnes malo na vetsinu veci, nejen eclipse. My v praci taky prikupovali na 8

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 11:50 | Nahoru | #38

dizzi píše: V podstate jo, vsechny ty rychlostni porovnavani tech jazyku jsou pomerne irelevantni protoze (ne)spravna implementace/vyuziti vlastnosti jazyka obycejne udelaji tak velky rozdil, ze rychlost samotneho jazyka je nepodstatna.

1GB ram uz je dnes malo na vetsinu veci, nejen eclipse. My v praci taky prikupovali na 8


Ja ten notebook uz nepouzivam. Jen kdyz nekam jdu. No ale taky budu ted kupovat 8GB do PC pac mi tu bezi VMWare a dalsi kraviny. A nebo se zbavim firefoxu. Pac to je neco silenyho. Ja resetuju PC jen jednou za tyden. A mel jsem tam 20tabu a on mi sezral 2GB RAM. A ty 4GB mi dosly . Jeste zkusim vypnout co nejvic doplnku. I kdyz tam nis brutalniho snad nemam

Ale cim dyl bezi, tim bere vic. A snad jako kdyby to se zaviranim tabu ani neuvolnoval

Naposledy editováno 29.12.2011 11:52:53

(reakce na) OT:Instrukce AMD

29.12.2011 v 11:59 | Nahoru | #39

SVSkritek píše: Ja ten notebook uz nepouzivam. Jen kdyz nekam jdu. No ale taky budu ted kupovat 8GB do PC pac mi tu bezi VMWare a dalsi kraviny. A nebo se zbavim firefoxu. Pac to je neco silenyho. Ja resetuju PC jen jednou za tyden. A mel jsem tam 20tabu a on mi sezral 2GB RAM. A ty 4GB mi dosly . Jeste zkusim vypnout co nejvic doplnku. I kdyz tam nis brutalniho snad nemam

Ale cim dyl bezi, tim bere vic. A snad jako kdyby to se zaviranim tabu ani neuvolnoval



Taky jen hibernuju, a chrome ted peknych 900MB :D Asi si nepomuzes, vypnout flash, pozavirat taby co nejsou treba resp restartnou prohlizec...

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 12:23 | Nahoru | #40
dizzi>

Zkousel si to? (to spojovani tech stringu)


přiznám se, nezkoušel, četl . Používám StringBuildery, tak mě nenapadlo se v tom víc štourat. Je mi jasný, že ne vždy si bude compiler tak jistej, aby to vyřešil sám.

coz prakticky znamena ze ti to treba zhuci na out of memory na stacku


Nojo, ale to máš buď tak málo paměti, nebo si se někde děsně zacyklil a není z toho cesty ven.

Kolik casu stoji to prealokovani ty kolekce nebo to kdyz blbej programator neresi v jakem case se prvky vyndavaji/pridavaji a ktera operace je rychlejsi?


No, jasně že nesprávnou kolekcí si může věc zkomplikovat. Ale nestane se mu, že tak dlouho iteruje, až už čte špatný data, aniž by o tom věděl. Taky se mu nestane, že prostě zapomene uvolňovat paměť, ve většině případů to udělá GC za něj. Ale kdo ze začátečníků nezapomíná uvolňovat paměť v céčku?

a nevim teda jak levne to vyjde kdyz musi resit i vyvoj samotneho PHP :)


Asi vyjde levněji zaměstnat pár špičkovejch odborníků, co budou optimalizovat PHP a spoustu lepičů, co to v něm budou psát. Navíc to hloupý PHP je cesta, jak zpřístupnit rozšiřování funcionality davům.

Ja mam Javu rad, a ano i to hloupe napovidani editorem v realnem case zacatecnikovi pomuze, ale rikat "naplacej to tam jak chces, on si to nejak prekouse" je presne ten duvod proc dnes mame 20x rychlejsi stroje, a stejne rychly software...


Oni taky ty dnešní aplikace dělaj výrazně víc věcí, než ty před mnoha lety. Jasně že tohle je zjednodušenej pohled. Ale když posadíš začátečníka k céčku a k javě, ten v javě bude mnohem úspěšnější v tom, co vytvoří, bude mít míň chyb a nejspíš výkonnější program. A to napovídání je zas možný jen proto, že je java staticky typovaná a díky tomu nad ní můžou běžet všechny ty statický analyzátory jako PMD a zase snižovat šanci na chybu, co se dostane do produkce. Já dávám určitě větší váhu na spolehlivost než výkon.

Nakonec, přestože větší část věcí píšu v javě, je mi jasný že není na všechno dobrá. Kupu jednoduchejch věcí člověk udělá líp v pythonu, javascriptu i bashi. Java není všespasitelná. Ale je dost dobrá na to, aby běžela od telefonů po servery. Kdyby byla tak zoufale nevýkonná, jak se traduje, těžko by se v ní psaly mobilní aplikace, kde není zdrojů nazbyt.

2 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 12:26 | Nahoru | #41
dizzi>

1GB ram uz je dnes malo na vetsinu veci, nejen eclipse. My v praci taky prikupovali na 8


Oni nakonec ty paměťový moduly stojí několik málo stokorun, vyjde to výrazně levněji než trávit měsíce optimalizacema Je to takovej konzumní pohled, ale tak to prostě je. Firmu vyjde výrazně levnějí vyměnit železo, než platit měsíc programátora, co bude jen ladit drobnosti okolo výkonu.

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 12:32 | Nahoru | #42

todvora píše: dizzi>
Oni taky ty dnešní aplikace dělaj výrazně víc věcí, než ty před mnoha lety. Jasně že tohle je zjednodušenej pohled. Ale když posadíš začátečníka k céčku a k javě, ten v javě bude mnohem úspěšnější v tom, co vytvoří, bude mít míň chyb a nejspíš výkonnější program. A to napovídání je zas možný jen proto, že je java staticky typovaná a díky tomu nad ní můžou běžet všechny ty statický analyzátory jako PMD a zase snižovat šanci na chybu, co se dostane do produkce. Já dávám určitě větší váhu na spolehlivost než výkon.

Nakonec, přestože větší část věcí píšu v javě, je mi jasný že není na všechno dobrá. Kupu jednoduchejch věcí člověk udělá líp v pythonu, javascriptu i bashi. Java není všespasitelná. Ale je dost dobrá na to, aby běžela od telefonů po servery. Kdyby byla tak zoufale nevýkonná, jak se traduje, těžko by se v ní psaly mobilní aplikace, kde není zdrojů nazbyt.



Jeste porypam (o nic nejde ale mam dovolenou )

C je taky staticky typovane, ostatne eclipse CDT nebo VC to dokazou jakz takz taky, ale asi je se treba podivat kdy vznikla java a kdy c a s jakymi pozadavky v hlave ji vytvareli.

Jinak muj nazor je ze si lidi javu spojuji s tim ze je pomala proto, protoze dlouho trva start JVM, a v dobe appletu byl pomaly net.

(reakce na) OT:Instrukce AMD

29.12.2011 v 12:37 | Nahoru | #43

todvora píše: dizzi>
Oni nakonec ty paměťový moduly stojí několik málo stokorun, vyjde to výrazně levněji než trávit měsíce optimalizacema Je to takovej konzumní pohled, ale tak to prostě je. Firmu vyjde výrazně levnějí vyměnit železo, než platit měsíc programátora, co bude jen ladit drobnosti okolo výkonu.



Problem je ale udrzitelnost, kdyz je hod jeden velkej bordel, pridat vlastnost te vychazi mnohem draz, resp chyby ktere tim pridas...

Navic kod se 1x pise, ale 1000x cte. Takze napsat ho dobre, v konecnem dusledku drazi neni. (neni to ale videt, protoze managery zajima jen obdobi do nejakeho releasu)

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 12:40 | Nahoru | #44

SVSkritek píše: K te Jave vs C++ . Pred 6-7 lety na Stredni jsme na stahoavni torrentu pouzivali Azureus (Java). Upravoval jsem i nejake drobnosti ve zdrojacich. Udelal jsem si verzi ktera cheatovala na private Torrent trackerech a dava falesne udaje o mnozstvi uploadovanych dat.

No ale k veci. Narocnost na HW byla silena (pri rychlosti stahovani treba 3 MB/s , meli jsme tam optiku). A uTorrent napsany v C++ to same zvladl s mnohem mensim vytizeni a spotrebou CPU.



Presne tak ... a v nejakem programovacim jazyku - treba v C - by to bylo jeste uspornejsi .

(reakce na) OT:Instrukce AMD

29.12.2011 v 12:47 | Nahoru | #45
dizzi>

Problem je ale udrzitelnost, kdyz je hod jeden velkej bordel, pridat vlastnost te vychazi mnohem draz, resp chyby ktere tim pridas...

Navic kod se 1x pise, ale 1000x cte. Takze napsat ho dobre, v konecnem dusledku drazi neni. (neni to ale videt, protoze managery zajima jen obdobi do nejakeho releasu)



No, a právě proto to v javě bude nejpíš mnohem čitelnější a snáz se bude později kód refactorovat, už jen proto, že nedovolí tolik co céčko. Nakonec, python třeba už jen tím povinným odsazováním vnucuje jakousi úrověň kódu. Ostatně, ta čistota kódu a udržitelnost mě dost zajímá, proto značnou část pracovní doby věnuju různým QA nástrojům, pluginům pro CI server, psaním testů a pod.

Já myslím že nakonec se celkem shodneme a souhlasím s těma posledníma příspěvkama, co píšeš Nakonec to není ani tak o jazyku jako o programátorovi. Jazyk je jen prostředek a nebejvá vyloženě dobrej ani špatnej...

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 12:48 | Nahoru | #46

Medved píše: Presne tak ... a v nejakem programovacim jazyku - treba v C - by to bylo jeste uspornejsi .



Nepovidej, a jake ze to jsou rozdily mezi C a C++ co by usetrily?

(reakce na) OT:Instrukce AMD

29.12.2011 v 12:50 | Nahoru | #47

dizzi píše: Asi si cetl jiny prispevek nez jsem napsal :) Ja jsem nerek ze java je pomala, ja rek ze to prasi programatori. Nesikovny programator rozhodne kvalitnejsi vec nenapise, napise ji jen rychlejc. Typicky zbytecna alokace/pouziti kolekci, spojovani stringu a co ja vim co.

ER lang sem uved jako priklad uplne jineho pristupu, dokaze veci o kterych se jave nesni a naopak, obecne je ale asi nema smysl porovnavat...



Jsou to bohuzel oba duvody - jednak tzv. programatori (tzn. ti, kteri dokazi akorat slepit k sobe dva javovske moduly stazene z netovych stranek indickeho bastlice) dokazi zprasit neskutecne veci a druhak je java opravdu dost rozezrana co se tyce CPU a hlavne pameti.

Pokud v jave nebudes pouzivat vsechny "vymozenosti" ktere nabizi, co ti z ni zbyde? Trosku hloupejsi a pomalejsi C.

Oblibena replika meho kolegy je: "Az v Jave, C++ nebo v C# nekdo napise nejaky pouzitelny OS, potom uznam ze je to programovaci jazyk. Do te doby je to script.". Ja bych tolik radikalni nebyl - moje oblibena replika je: "Kazdy programovaci jazyk ma nejakou svou oblast pouziti - C a Python jsou na programovani, Perl je na zlost, C++ a Pascal na vyuku a Java na testovani robustnosti systemu".

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 13:14 | Nahoru | #48

dizzi píše: Nepovidej, a jake ze to jsou rozdily mezi C a C++ co by usetrily?



nesmis kazde rypnuti brat az tak vazne .

Ale treba ve volani konstruktoru/destruktoru se C++ jiste zdrzi (i kdyz budou konstruktory inline), volani metod take nepatri zrovna k uspornym castem C++ kodu ... na druhou stranu asi by to musela byt extremni aplikace, aby se rozdil mezi dobre napsanym kodem v C a C++ nejak znatelne projevil.

Na C++ mi zasadne vadi jedina vec - dava spoustu prostoru pro napsani nekorektniho anebo alespon naprosto nesrozumitelneho kodu. Mnohem vic nez C. Je to logicke, pouziva daleko vetsi miru abstrakce nez C.

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 13:22 | Nahoru | #49

todvora píše: dizzi>
Oni nakonec ty paměťový moduly stojí několik málo stokorun, vyjde to výrazně levněji než trávit měsíce optimalizacema Je to takovej konzumní pohled, ale tak to prostě je. Firmu vyjde výrazně levnějí vyměnit železo, než platit měsíc programátora, co bude jen ladit drobnosti okolo výkonu.



Hm, to je ale uplne mimo. Toho programatora plati firma, ktera ten kod produkuje. To zelezo plati firma, ktera ten kod pouziva .

Neni trapnejsi situace, nez kdyz prodas nekomu nejakou aplikaci s tim, ze mu pobezi na 16G pameti a pak mu vysvetlujes, ze si tam musi prikoupit dalsich 16G, protoze mas prasecky napsany kod a ackoli v testech ti to na 16G bezelo krasne, v realnem pouziti ti tech 16G sezere JBOSS s GUI a aplikaxni procesy jedou ve swapu. A Kdyz JBOSSovi dovolis jenom 8G pameti, tak se na to GUI pripoji tri lidi a kliknuti trva 3s.

2 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 13:24 | Nahoru | #50

Medved píše: nesmis kazde rypnuti brat az tak vazne .

Ale treba ve volani konstruktoru/destruktoru se C++ jiste zdrzi (i kdyz budou konstruktory inline), volani metod take nepatri zrovna k uspornym castem C++ kodu ... na druhou stranu asi by to musela byt extremni aplikace, aby se rozdil mezi dobre napsanym kodem v C a C++ nejak znatelne projevil.

Na C++ mi zasadne vadi jedina vec - dava spoustu prostoru pro napsani nekorektniho anebo alespon naprosto nesrozumitelneho kodu. Mnohem vic nez C. Je to logicke, pouziva daleko vetsi miru abstrakce nez C.



Tak to teda nevim, zas tak moc jsem toho v C/C++ nedelal, ale po precteni knizek typu Thinking in C++ ktere rikaji treba ze kolikrat kdyz clovek pusti C++ kompiler na C kod, objevi mnoho chyb, resp ze jeden z hlavnich crtu C++ je vetsi bezpecnost a odchytavani chyb v dobre prekladu, mi ty radky nahore prichazeji rozporuplne. Navic objekt jako takovy je vlastne struct takze nevidim duvod proc by neco melo byt pomalejsi. (ano v momente kdy nasadis virtualni tridy/polymorfizmus ktery se vaze az za behu, tak to nebude super rychle, ale to bude tim, ze to same v C neudelas)

A mimochodem ruzne to tu problesklo... ale python opravdu neni seriozne pouzitelny programovaci jazyk (ano vim je to silny nazor )

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 13:27 | Nahoru | #51
Medved>

Hm, to je ale uplne mimo. Toho programatora plati firma, ktera ten kod produkuje. To zelezo plati firma, ktera ten kod pouziva .


To je dost omezenej předpoklad. Třeba mě platí ta samá firma, která ten kód provozuje na svým železe. Děláme webový aplikace a sami si je provozujem na svejch serverech.

Pokud nastane taková situace, jakou popisuješ, pravděpodobně se někdo dost vyflákl na testování/zátěžový testy, jinak by se na to přišlo mnohem dřív, než po předání produktu.

2 reakcí na tento příspěvek OT:Instrukce AMD

29.12.2011 v 13:28 | Nahoru | #52
sry za ot, ja programoval akorat intel 8086, 8051 v ASMB a v C++, takze vam do toho nebudu mluvit, ale nejak jste mi pripomneli tohle:

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 13:30 | Nahoru | #53
Sleeper1> Ja jsem ten druhej zleva.Akorat mam o neco svetlsi vlasy. Bud rad ze uz neprogramujes. Je to hruza. Se mnou se ani neda normalne bavit kdyz to neni o PC nebo motorkach

2 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 13:31 | Nahoru | #54
dizzi>

A mimochodem ruzne to tu problesklo... ale python opravdu neni seriozne pouzitelny programovaci jazyk (ano vim je to silny nazor )



S tím musím nesouhlasit. Python je na něco perfektní. Třeba na lehký malý scripty, na prototypování, a věřím že se v něm seriózně dá dělat. Já mám v pythonu sady scriptů pro kontroly zdrojáků, crawlování webů, zpracovávání logů a podobně. Dokud jde o věc na pár set řádek, nevidím v tom problém. Rychle se to napíše, rychle se to upravuje, čitelnost je dobrá. Výkon mě netrápí. A když věc přeroste do něčeho velkýho, tak se ten prototyp prostě jen přepíše do jinýho jazyka.

(reakce na) OT:Instrukce AMD

29.12.2011 v 13:32 | Nahoru | #55
Sleeper1> Ne všichni z FAV jsou takový!

(reakce na) OT:Instrukce AMD

29.12.2011 v 13:32 | Nahoru | #56
SVSkritek> TVL fakt ti je podobnej!

e: hele ten obrazek je "joke", znam hodne lidi z FAVky.....takze vim...

Naposledy editováno 29.12.2011 13:33:28

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 14:53 | Nahoru | #57

todvora píše: dizzi>

S tím musím nesouhlasit. Python je na něco perfektní. Třeba na lehký malý scripty, na prototypování, a věřím že se v něm seriózně dá dělat. Já mám v pythonu sady scriptů pro kontroly zdrojáků, crawlování webů, zpracovávání logů a podobně. Dokud jde o věc na pár set řádek, nevidím v tom problém. Rychle se to napíše, rychle se to upravuje, čitelnost je dobrá. Výkon mě netrápí. A když věc přeroste do něčeho velkýho, tak se ten prototyp prostě jen přepíše do jinýho jazyka.



:) jo, jen vime jak to chodi, na webu daily wtf byvaji super clanky, a jedna z hlasek ktera se mi zaryla do pameti byla:

It was at this point that Jason decided Skynet wasn't a rogue military AI, but a mail merge macro trying to recover from a badly formatted postal code.



resp


...but after a certain point, this code ceases to be "just crappy VBA macros" and becomes "MISSION CRITICAL SOFTWARE OMG!"



A temhle dvou vecem se nikdy nevyhnes :)

(reakce na) OT:Instrukce AMD

29.12.2011 v 15:52 | Nahoru | #58
dizzi> Ale jo, někdy dočasnej hack slouží dýl, než všechen kód okolo. Ale nebudu brát kanón na vrabce, když chci napsat lehoučkej script, kterej si stáhne stránku, z ní vyparsuje data a předá je dalšímu programu ke zpracování (typicky třeba webový rozhraní tiskárny - python_script - nagios).

OT:Instrukce AMD

29.12.2011 v 21:29 | Nahoru | #59
Jeden muj spoluzak z VUT umel C++ lip nez cestinu a ten panecku s tim umel carovat

1 reakcí na tento příspěvek (reakce na) OT:Instrukce AMD

29.12.2011 v 21:38 | Nahoru | #60
Bludevil> Mozna u toho chlastani a huleni zustanu,ale je ted potreba se zamyslet nad budoucnosti a ver me ze me zadna slecna,divka,zena ci devka zivit nebude
Pro vložení příspěvku se musíte přihlásit nebo registrovat.


TOPlist