Vlákno názorů k článku Kdy přijdou programátoři o práci? od Michal Illich - Pod slovo "programátor" se vejde leckdo - ten,...
-
Článek je starý, nové názory již nelze přidávat.
- Podle hodnocení
- Podle vláken
- Nejnovější
-
Michal Illich (neregistrovaný)Pod slovo "programátor" se vejde leckdo - ten, kdo umi jen PHP+SQL (v horším ani to ne, jen nevalidní html a javascript), i ten, kdo je schopen navrhovat velké a efektivní systémy a naprogramovat je v céčku, přičemž rozumí "složitosti" a podobným důležitým pojmům. (a občas se jako programátor chce označovat i ženština, která umí napsat sčítačí makro v excelu)
Zatímco těch prvních programátorů je skutečně spousta, ti druzí jsou bohužel téměř nenalezitelní.
*
A mimochodem, myslím, že v článku je metodická chyba - z toho, že klesl podíl IT nabídek na celkovém podílu nabídek, se nedá usuzovat na uplatnění v oboru. Tipuji, že ta změna poměru vznikla naopak tím, že se i e-recruitmentový server začal zabývat i jinými místy - proto, že vzrůstá penetrace internetu i mezi netechnickými uživateli.
-
Ondra (neregistrovaný)To je fakt, ale ještě se pod pojmem programátor může skrývat něco dalšího. Když jsem kdysi na vojenské správě na otázku jaké je moje povolání odpověděl programátor, tak následovala otázka "A umíte pracovat na PC?" Nepředpokládám, že si myslela, že programuju na Macovi, něčem velkém nebo nějaké jednočipy, o tom laik normálně ani neví, že existuje, ale spíš si myslela, že vytvářím nějaké estrádní programy :-)
-
Vítězslav Novák (neregistrovaný)No, to záleží na tom, ve které době to bylo.
Bývávala doba, kdy počítač byla taková ta velikánská bedna (nebo hodně beden) v klimatizovaném sále.
Takže někdy v 89. jsem už byl celkem zkušený programátor s pár projekty za sebou, ale o PC jsem věděl to, že jsem jednu takovou mašinu viděl v Maďarsku na Váci utca za výkladem. (A málem jim ten výklad poslintal...)
U nás se tenkrát slušovické AT prodávalo skoro za čtvrt miliónu korun. A že koruna tenkrát a koruna dneska...
Občanská pracovnice z OVS taky mohla mít hluboko do 90. let představu, že děláte na EC 1040 či něčem podobném. -
Řezza (neregistrovaný)Jee, vojenská správa, těm jsem to taky nevystvětlil... Tak jsem skončil jako "strojní mechanik", protože jsem studoval SPŠ... Prostě programátor můžu být až po VŠ... To že už jsem něco stihl udělat, to co ta baba nedokázala za celý život, to už je jedno... Mimochodem, za programátora se moc nepovažuji, dokonce se za to i trošku stydím, je to už těžce jeté slovo...
-
Vítězslav Novák (neregistrovaný)Když už jste se zmínil o té OVSce, mám historku z vojny.
Narukovalo nás k pluku takovejch 20-30 absíků. Na konci přijímače nás rozřaďovali, už jsem se těšil, jak se dostanu k počítači...
No, nakonec šli k počítači dva dřevařští inženýři (študovalo se to někde na Slovensku; príma kluci, chlastat vydrželi hodně, asi museli kvůli hajnejm a tak...), matfyzáci a čvuťáci šli velet.
A možná to bylo dobře. Počítač byly dva náklaďáky s přívěsama, program zadrátovanej někde v bednách pod třema pečetěma a jediný co se nastavovalo, byly souřadnice. Nastavovaly se propojkama na kolíky na ovládací desce.
Ale je fakt, že ty souřadnice cíle to počítalo dobře.
Byla v tom příšerná zima, tak kluci od počítačů hlavně sekali dříví do kamínek. Vzdělání se jim hodilo. -
Petr (neregistrovaný)kdo umi jen PHP+SQL (v horším ani to ne, jen nevalidní html a javascript), i ten, kdo je schopen navrhovat velké a efektivní systémy a naprogramovat je v céčku
To jako ze ten kdo umi 'C' je neco lepsiho nez ty co umi 'jen' PHP+SQL? Proc? I v PHP se daji napsat velke projekty a i v C se da udelat ptakovina!
PS: prestoze delam v PHP tak trome toho umim i par dalsich veci. No a co.
-
Michal Illich (neregistrovaný)Ta spojka 'a' značí, že jde v té větě o obojí (navrhovat efektivní systémy A zároveň je umět naprogramovat v jazyce, který je k tomu vhodný). O tom, že v céčku se dá udělat blbost a i v jiném jazyce něco dobrého, není sporu.
(a abych zabránil i jiným pokusům zrodit flame: céčko byl pouze příklad jazyka, v kterém lze dělat rychlé programy, samozřejmě že jich existuje i bezpočet dalších; také nemám nic proti PHP).
-
Michal Illich (neregistrovaný)> Znamena to, ze nejlepsi je strojak?
Treba z pohledu zamestnavatele je to jednoduche: nejlepsi je to, co dobre splnuje ukol, a ma to nejnizsi naklady. Naklady jsou cas programatora krat plat programatora plus doba behu programu krat cena strojoveho casu.
Z tehle rovnice pro konkretni projekt obcas vypadne jako nejlepsi PHP (umi ho kdekdo, bastli se v nem rychle a pohodlne) a nekdy treba cecko (program pobezi rychleji). Strojak v soucasne doby asi malokdy (programovani v nem trva obvykle nasobne dyl a urychleni je oproti cecku minimalni, pokud vubec nejake). -
Vítězslav Novák (neregistrovaný)Tohle bych podepsal.
Jen snad to, že jsou aplikace, kde "doba běhu větší než něco" už znamená, že náklady jsou nekonečné. Respektive, že aplikace je nepoužitelná. No, a tam náklady na programátora můžou být zanedbatelné.
Kromě toho ale céčko taky programátora vychovává. K pořádku, ke slušnému programování. To neznamená, že by ho automaticky vedlo. Naopak! Napsat se v něm dají úplné prasárny, kterým za hodinu nebude rozumět ani autor, a přesto poběží. A správně.
Jenže když to někdo párkrát udělal, nebo nezkontroloval výsledek mallocu, přetekl pole,... To se pak snaží programovat pořádně.
Můžete mi to věřit. Drahá zkušenost.
Prostě - céčkař se naučí poměrně snadno jakýkoli procedurální jazyk. Obráceně bych na to moc nespoléhal. -
PaJaSoft (neregistrovaný)Z hlediska stroje urcite...
Ale na rozdil od Vasi velmi jizlive poznamky jsem soudny a mohu Vas ujistit, ze kompilator jazyka C jste schopen bez problemu v tomto jazyce implementovat (vcetne operacniho systemu kde vznikl - ostatne jazyk C byl jen pruvodni produkt, stejne jako treba mnoho technologii pri vyvoji Mozilla) - dokazete to same v PHP? Pokud porad nechapete rozdil mezi ruznymi stupni abstrakce, smula, diskuse na toto tema s Vami nema smysl...
-
PaJaSoft (neregistrovaný)A udelal jste to? Jinak zrejme jste spatne cetl, ale ja se bavil o kompilatoru C v C a o kompilatoru PHP v PHP... - uz vidim, jak v HTML strance na strane serveru poustite kompilator PHP, kteremu predhodite nejaky PHP zdrojak a on vyplivne vysledek (kdepak asi server prisel k includum na strane klienta bez specialni podpory mimo zakladni HTTP?)... - udelejte a pak mluvte!
-
ondrej (neregistrovaný)Nevim proc bych mel delat neco tak nepraktickeho :) slo mi jen o principialni moznost to provest. Nerozumim proc by PHP nemohlo mit k dispozici normalni moduly jako prace s filesystemem ? Cecko se taky neobejde bez standardni knihovny a bez assembleru. Me prijde jakoby jste rikal ze C je skvele protoze nepotrebuje moduly napsane v jinych jazycich a da se v nem napsat uplne vsechno a tim je jakoby nadrazene .... ale koho tohle zajima ? To pak bude nejskvelejsi assembler, protoze (skoro) v nicem jinem se treba neda psat operacni system.
-
PaJaSoft (neregistrovaný)Vidite - sam citite, ze je to neprakticke, ale implementovat kompilator jazyka C v jazyce C je naprosto bezna vec a kupodivu se tak bezne deje...
U PHP byste musel zajistit spoustu veci a to nejen syntaxi jazyka {kterou bohuzel/bohudik neoplyva), ale i modulu... u PHP vsak ted narazite na syntakticka omezeni jazyka...
Assembler je dobra vec, ale je zajimave, ze na psani OS se v soucasne dobe pouzivaji jazyky C, pripadne C++, ci jine OBJEKTOVE (treba NextStep IMHO neni ani v ASM, ani C/C++)... A kupodivu ani Linux nebyl stvoren v assembleru, ale v jazyce C... - ASM moduly se doplnily pozdeji (a nutno pro kazdou platformu)...
Ostatne, kdyz uz jste u techjazyku vs. OS, nekde jsem cetl, ze vnitrnosti MS DOSu byly implementovany pomoci cele plejady jazyku (mam potvrzeno) - Assembler, Pascal, C, Basic, SmallTalk, Clipper, C++ (pozdejsi verze DOSu) - skutecna dzungle, vidte...
-
ondrej (neregistrovaný)Ne necitim, me by totiz v zivote ani nenapadlo nic takoveho delat, o prakticnosti nemluve, sam nemam rad web aplikace obecne natoz abych pokladal za prakticke v nich psat prekladace :) Nejde mi o prakticnost, ale jen o pouhou moznost to provest. PHP si proste muze zchroustat text a vyplivnout binarku, staci mu k tomu zakladni I/O.
S tim asm a OS jsem se dost spatne vyjadril. Na psani celeho OS se samozrejme asm pouziva malokdy, me slo o to ze mala _cast_ proste v asm byt MUSI - C si tedy taky nevystaci ve vsem samo, stejne jako PHP. A predevsim, nezalezi na tom. Radsi pouziju neco podobneho "nesamostatnemu" PHP, nez abych se patlal s nejakym realloc(), str[n]cpy(), void* apod. Radsi to nebudu dal rozvadet, na flameware s ceckarema mi nejak chybi nalada ;-)
Myslim ze OS by sel napsat i v tom PHP (samozrejme ne v ramci HTTP serveru ;-) ), jen by ta ne-PHP cast byla vetsi nez ta ne-C cast v C-kernelu.
-
ondrej (neregistrovaný)Na zaklade me (chabe) znalosti protected modu - z C proste tezko budete pouzivat ruzne specialni registry a instrukce potrebne pro virtualni pamet nebo multitasking. Nemluve o psani bootsektoru nebo prepinani do protected modu.
Minix nenapsal Linus, ale Andrew Tanenbaum (http://www.cs.vu.nl/~ast/)
V kazdem pripade bez znalosti assembleru nedate pri psani zakladnich veci kernelu ani ranu. -
PaJaSoft (neregistrovaný)Ja jsem nepsal o tom, ze Linus psal Minix - kdybyste toho o historii Linuxu a pohnutek k jeho napsani vedel vice, pochopil byste...
Jinak k tomu dalsimu - prepinani, VM apod. - nejsou to nahodou takove ty nesmysly, kteryma nas oblazil Intel, pred vice jak 18 roky? Skutecne jine architektury maji tak zblastleny navrh a pozadavky?
A posledni - zadefinoval jste co to je pro Vas kernel, ze tvrdite takove obecne naprosto mylne tvrzeni?
PS: Co treba cele JVM - ano dneska vetsinou jeste SW, otazka HW JVM je zajimava a verte, ze i Intel pracuje, co potom pro Vas bude kernel a co user space?
-
ondrej (neregistrovaný)> Ja jsem nepsal o tom, ze Linus psal Minix
Jak si potom mam vysvetlit slova "Nevybavuji si, ze by Linus na zacatku oplyval temito znalostmi a presto Linux/Minix v jeho podani skutecne existoval..." ?
Pred 18 lety, asi ano, proc nesmysly ? Spis funkce co z x86 udelaly procesor pouzitelny pro psani poradnych operacnich systemu. Zbastlenost protected mode v 386 nedovedu posoudit, a jak to souvisi s (ne)moznosti napsat kernel bez znalosti assembleru, to taky nechapu.
Pod pojmem kernel jsem myslel neco typu linux, NT kernel, Mach, L4, QNX, blablabla atd. atd. Implementace JVM napr. od Sunu se rozhodne neda povazovat za kernel. Pokud takove JVM povazujete za kernel a moje tvrzeni interpretujete pomoci spatne vylozenych pojmu, je to vase chyba, ne moje. Ja o kernelu v tomto smyslu v kazdem pripade nemluvil. Mluvil jsem o kernelu tak, jak se dnes zhruba chape. A tam moje tvrzeni plati.
A az se bude po startu pocitace bootovat JVM, bude opet platit: bez znalosti asm vcetne systemovych funkci procesoru takovou JVM nenapisete.
-
PaJaSoft (neregistrovaný)Prvni dotaz je jednoduchy - treba tak, ze prvni verze Linuxu byl Minix ve free kabate, zhruba tak, jako MS DOS 1.0 bylo CP/M prepsano z ASM I8080 do I8086.
x86 architektura se tahne jiz 25 let, ve sve dobe mela mozna sve opodstatneni, velmi malo se ale vi, ze I8086 byl takovy bastl prave proto, ze Zilog se svou Z80 byl jiz napul 16-ti bitovy (mel cast aritmetiky 16-bitovou, nektere registry byly 16-ti bitove...) a Intel citil, ze ztraci dech... - proto vzal I8080 (ktery zacal u I4004 - pokud jste ho nekdy videl na fotce, tak i studak by se za to stydel), rozsiril ho na 16 bitu a mel 16-ti bitovy procesor, na rozdil od Zilogu, ktery pracoval na opravdu kvalitnim zaklade.... - bohuzel pro CPU historii to Intelu proslo, zhruba asi tak Gatesovi haluz s MS DOS (vite, co mel a co Gates nasliboval, ze v roce 1986 bude MS DOS umet? - ja trochu ano... skoda, ze sef DECu byl na vode...:-(). Jenze jiz v dobe x86 architektury tu byly jine, chcete rici, ze UNIX pro PDP a jine davno zapomenute systemy byl psan v ASM? Proc tedy vubec jazyk B a pozdeji C vznikl?
Pod pojmem kernel ovsem popisujete neco, co ma sve koreny casto v x86 architekture s BIOSem apod... - zapomente na x86 a reknete mi, co je OS v pripade Z80 ci Z8000, reknete mi co je OS v pripade, ze zapnu pocitac, nabehne procesor a zacne vykonavat JVM - co se stane, kdyz se zinicializuje mikrovlnka ci jine elektronicke zarizeni? Co se stane, kdyz zapnu mobil, ktery ma ovladani implementovane pomoci Java, co se stane, kdyz Xscale procesor (opet Intel) bude nativne vykonavat byte kod javy? Kdepak mame ten kernel o kterem mluvite (ja znam z tohoto pohledu jen objekty a ruzne casti Java API a pridruzenych technologii)?
Mozna pouzivate jen podivne pojmoslovi, ale co myslite systemovymi funkcemi procesoru? Ja znam, ze procesor ma nejake I/O s periferiemi (do cehoz patri komunikace pomoci preruseni (IM2, NMI, INT...), komunikace pomoci I/O (IN, OUT), pomoci pameti (vcetne sdilene a mapovane), pomoci rezervovanych instrukci (soucasti instrukce je prikaz ci data)), ALU, blokove operace (pametove presuny) a jednotku pro rizeni toku behu (CALL, podminene/nepodminene skoky, smycky...). Podivejte se jak uvnitr vypada treba Crusoe...:-). O nejakych systemovych funkcich nic nevim, co mate na mysli?
-
ondrej (neregistrovaný)> chcete rici, ze UNIX pro PDP a jine davno zapomenute systemy byl psan v ASM?
Ne, proc? Opakuji se: netvrdim ze se v asm pise cely zaklad systemu, to dneska napadne mozna par asm-maniaku ale nikoho soudnyho.Uz je to jasne? Super.
> zapomente na x86 a reknete mi, co je OS v pripade Z80 ci Z8000, reknete mi ..........
1) O pojmu "OS" se tu nehadam.
2) Pojem kernel se rozhodne nijak neomezuje na x86.
3) Kde jsem tvrdil ze se v kazdem pocitacim stroji vyskytuje hranice mezi kernelem a aplikacemi ? Netvrdil. Vsechno to muze bezet treba na nejvyssim privilegiu, ve stejnym adresovym prostoru atp. Hezky, nerikam ze to neexistuje. Jedine co jsem tvrdil bylo, ze vsechen SW psat bez znalosti funkci procesoru proste nejde. Napr. zaklad te casti, ktere se normalne rika "kernel". Tot vse.
Pokud nekde funkcnost kernelu splyva se zbytkem SW nebo uplne chybi, tak co ? Nekde kernel je, nekde neni, nekde se ta hranice rozplyva vic nez jinde. No a co ? Pojem kernel neztraci smysl.
A co jsou ty "systemove funkce procesoru" ? Funkce podporujici zakladni "systemove programovani", napr. memory management, task management, a tak. Psani zakladu OS. Napr. manualy od Intelu "System programming". Funkce nepouzivane "aplikacemi". Na nejakych systemech rozlisovani mezi "systemem" a "aplikacemi" treba nema smysl, jenze na nekterych zase ma.
-
PaJaSoft (neregistrovaný)Fajn, konecne Vam trochu rozumim, takze bych rad slysel, kde je kernel v pripade, ze mam procesor, na nem bezi JVM a nem Java aplikace. Systemove funkce procesoru zajistuje JVM (tak jak jste je jmenoval - memory, task, sync a I/O management) a procesor vykonava byte kod Javy... - kde je v tomto pripade ten nutny kus ASM, aby se to vubec rozjelo? Tocime se stale dokola, vy tvrdite, ze jsou cinnosti/kusy kodu, ktere nelze jinak nez v ASM udelat, ja tvrdim, ze dneska jsme jinde a ze Vase tvrzeni je chybne... Navic, znate jediny kompilator, ktery nejakou syntaxi ASM preklada do byte kodu Javy? Ja o zadnem nevim...
-
Vítězslav Novák (neregistrovaný)No, já bych řek, že si navzájem trochu nerozumíte.
Samozřejmě, že (skoro - budu opatrný) všecko jde naprogramovat ve vyšších jazycích a assembleru netřeba. Céčko vás pustí až "na křemík". Něco se vyplatí naprogramovat v asm kvůli rychlosti, ale dnešní kompilátory céčka jsou už tak vymakaný, že si člověk už musí opravdu hodně věřit (a oprávněně věřit) aby to dělal. Taky se může stát, že kompilátor využívá nějakou obskurní vlastnost konkrétního procesoru, takže z C přeložený kód bude rychlejší než assemblerovský.
Nesouhlasil bych ale s s tím, že procesor vykonává bytekód Javy. JVM interpretuje bajtkód a překládá ho do posloupnosti instrukcí procesoru. Procesor žádný bajtkód nezná.
Javista pochopitelně asembler nepotřebuje a ani používat nemůže. Asík je vždycky silně závislý na HW, je to vlastně jenom trošku opentlený strojový kód - aby si člověk nemusel pamatovat, že "ulož na stack" je 0x31 nebo dokonce 00110001, jako v dobách dřevěných a mohl používat jména místo číselných adres. Takže jeho použití v Javě by šlo proti platformové nezávislosti.
Javista prostě využívá toho, co mu někdo jiný ve formě classů a JVM připravil. Možná i v tom assembleru. -
PaJaSoft (neregistrovaný)S Vasim prispevkem vesmes souhlasim. Pouze jedina drobnost ohledne byte kodu a CPU. To, co pisete je samozrejme (take) pravda, dokonce i dneska vesmes plati - do dnes totiz mame JVM implementovane POUZE formou softwarovou, byt ruzne just-in time kompilatory skutecne odvadi spinavou praci a byte OP kody prekladaji do SOJ konkretniho CPU nad kterym ten JVM bezi...
Jak rikam, plati to vesmes, protoze jste zrejme nezaznamenali plan Intelu (SUN se o to pokousel uz v minulosti, udajne ciste Javovske procesory jsou, ale vyroba a veci okolo jsou v cene, ze je vyhodnejsi to nechat zpracovavat patricne dimenzovana pecka...) ze do novych procesoru Xscale (? - jmeno mozna neni presne) urcenych mimo jine do mobilnich zarizeni a jinych elektonickych inteligentnich pristroju zabuduje instrukcni sadu prave odpovidajici byte OP-kodum Javy pro nativni beh Javy... Takze pokud se to povede (jako, ze kdyz uz to takto vyhlasil Intel, tak to ma skoro dotazene do vyrobni linky), tak JVM a procesor v podstate jedno budou - procesor bude znat bajtkod a predhazovat se tomu budou classy...
-
Vítězslav Novák (neregistrovaný)Taky jsem o těch javových procesorech četl, počkám až budou.
Ale to je pořád jedna speciální platforma. Síla Javy by měla být mimo jiné v tom, že poběží všude. Tedy kromě toho, že se v ní nádherně vyvíjí.
Jo, souhlasím, že ne všude je nutný OS (BTW, i na 8080-kových počítadlech OS byl, i v CBM 3032, což mělo nějaký úplně jiný procesor - jehož číslo jsem slavně zapomněl - a nemělo disky, bylo cosi co by se dalo nazvat OS, i když to nikdo nedělal).
A rozhodně není nutno programovat v asíku. Ostatně mně taky moc k srdci nepřirostl. -
ondrej (neregistrovaný)Nevim kde je kernel, podle me vyznam pojmu kernel neni vseobecne sdilen tak presne aby se tohle dalo rozhodnout. Slovo kernel ma proste smysl hlavne v normalnich OS rozdelujicich veci na systemove a aplikacni. U vaseho JVM-OS kde se ochrana asi zajistuje spoustenim vyhradne verifikovaneho kodu a zadny kernel/user space neexistuje, by se daly identifikovat oblasti za ktere je normalne zodpovedny (mikro)kernel, to je asi tak vsechno.
> procesor vykonava byte kod Javy... -
> kde je v tomto pripade ten nutny kus ASM, aby se to
> vubec rozjelo?
Pokud si vymyslite procesor ve kterem to neni potreba, tak to potreba neni, to je jednoduche. Napr. u 386 to zase podle me potreba je a v tehle sfere se myslenkove pohybuju - to uznavam. Ja prece nebudu tvrdit ze pro psani zakladnich kousku systemu na jakemkoliv cpu bude na veky veku potreba jakysi blize nedefinovany jazyk "ASM" bez ktereho to nejde. I pro 386 se samozrejme da vymyslet specialni jazyk obsahujici prikazy pro praci se systemovymi registry apod. nebo prikaz prepni_se_do_pmode ;-) Proto jsem taky mimochodem o par prispevku vysi ve vete "To pak bude nejskvelejsi assembler, protoze (skoro) v nicem jinem se treba neda psat operacni system." obezretne ;-) pouzil ono slovo "SKORO".
> znate jediny kompilator, ktery nejakou syntaxi
> ASM preklada do byte kodu Javy?
Assemblery pro java bytecode prece existuji :)
-
PaJaSoft (neregistrovaný)Ad kernel - to co pisete ma smysl, ale rekneme nejakych 20 let a to jeste nekde. Vezmu OS MS DOS ci CP/M - kernel zde je co? BIOS? msdos.sys a io.sys pripadne tech 15 sluzeb nebo kolik jich bylo u CP/M verze 2? Ptam se - jak to vnimate vy.... Ja vnimam, ze pojem kernel, mikrokernel, mach apod. jsou pojmy, se kteryma se experimentovalo spise v akademicke casti (+experimentalni OS) a ma vyuziti jen ve specialnich pripadech, ostatne MS Win 3.1 (a mozna i 3.5) NT ten mach melo a i MS pochopil, ze tudy ne... takze kernel v pravem slova podani nakonec zustal jen u UNIX like systemu (+nejake historicke, coz IMHO uz rovnez nesplnuje tu "normalnost").
Potreba/nepotreba kernelu IMHO neni o CPU, ale o architekture elektronickeho zarizeni jako celku a jeho komunikaci...
A k tomu ASM pro byte kod - ja o zadnem nevim, ASM se bezne oznacuje jako Strojove Orientovany Jazyk (SOJ) k cemuz ma kompilator Javy dost daleko. Navic preladac ASM dela konverzi SOJ -> strojovy kod, to Javac nedela...
-
ondrej (neregistrovaný)Operacni systemy zabirajici dnes drtivou vetsinu desktopu i serveru (tedy win9x, winNT, unix-like, OS X) maji normalni kernel space a user space a celkem jasne vymezene kernely,
takze mi nepripada ze by se pojem kernel omezoval na akademickou sferu. I v "embedded" systemech se afaik cim dal tim vic zacinaji pouzivat podobne OS misto aby to bezelo "bez niceho". Na jave toho afaik moc nebeha.
Pojem mikrokernel zustal v akademicke sfere, bohuzel. NT sice o sobe prohlasovaly jaky nejsou mikrokernel ale postupne MS nacpal do kernelu co mohl. NT "mach" nemelo, "mach" neni obecny pojem ale nazev produktu (spis rodiny kernelu).
O dosu toho vim minimum, kernelem bych to asi nenazval, kernel si predstavuju jako neco bezici privilegovane coz se o dosu rict neda.
Tim assemblerem pro javu jsem samozrejme myslel preklad symbolicky zapsaneho java bytecode do binarne zapsaneho java bytecode, stejne jako se symbolicky zapsany x86 preklada do binarniho x86.
-
PaJaSoft (neregistrovaný)V MS Win9X a WinNT to teda jasne vymezene neni - pokud ano, pak kernel v podani MS je i GUI (+DirectX) a IE, protoze je v kernelu a 80% skutecne bezi s temi prioritami a moznostmi o kterych pisete - uz I80386 ma 4 "ranky"/urovne opravneni, vyuziva se do dnes jen hloupy model 0 - vse a 3 - user... (a to bohuzel i v modernich OS jako je Linux, Solaris...
Na Jave toho beha sakramentsky hodne a nejen v embedded systemech, zrejme o tom moc nevite, proto tuto oblast povazujete za okrajovou, nevadi, skutecnost je vsak jina...
S tim mikrokernelem je to mozna skoda, i MS ale dosel na to, ze hruby vykon nedostacuje na rozumny normalni vykon systemu takto zalozenem... - proto tento styl opustil. Bohuzel jak uz jsem psal, hruby vykon CPU stoupl nehorazne a rovnez nehorazne se zabil, misto toho, aby se vyuzil treba na komunikaci s mikrokernelem...
A kdepak se vali syntaxe toho "symbolicky zapsaneho java bytekodu"? Ja o zadne nevim - neco co by se blizilo AT&T ci Intel syntaxi? Nebo Sun uz udelal svou syntaxi? Ja opravdu o zadne nevim, prepis binarnich dat z jedne mnoziny do jine nepovazuji za assembler, to je JIT...
-
ondrej (neregistrovaný)Nejsem si jist s win98, ale u NT snad kernel celkem jasne vymezeny je. NT je prece delene na microkernel, exekutivu, ruzne "managery" atd. Ja bych sice kernel rikal tomu vsemu dohromady ..... no ale nejaky kernel tam proste je.
IE v kernelu ?? Myslel jsem ze IE je sice kriticka komponenta GUI (ve win98) ale prece neni v kernelu. Co by z toho microsoft mel ? Urcite snad nemuze byt v kernelu na w2000/xp server, to by byla hruza.
Co bezi na Jave vic, nez par embedded zarizeni a J2EE a par desktop aplikaci ?
S mikrokernely je to trochu slozite, Proste je nutne implementovat meziprocesovou komunikaci takove rychlosti aby byla srovnatelna s primym volanim kernelu nebo mezi komponentami bezicimi v kernelu, coz je problem. Na 386 pry prepinani mezi adresovymi prostory trva strasne dlouho kvuli vyprazdneni cache prekladu virtualnich adres pri takovem prepnuti, coz znamena chvilkove drasticke zpomaleni prekladu
adres po prepnuti. Nektere jine procesory timhle netrpi.
Takze to vypada ze cely problem tkvi v 386. Na druhou stranu se pozdeji ukazalo ze i pro tu 386 to jde, viz. treba QNX a L4 kde bezi v samostatnem procesu i drivery. Proste se hned neprislo na tu spravnou techniku (na 386).
Me se predevsim libi myslenka objektove orientovaneho OS. V beznem OS s pomalym IPC nezbyva nez vsechny objekty se kterymi je potreba komunikovat rychle nacpat do kernelu - nestabilni, nulova bezpecnost (pred kernel-mode komponentou se nejde nijak chranit), omezeny objem objektu. Nepripada v uvahu.
Mikrokernely se mi libi protoze
1) rychle IPC pouzitelne pro komunikaci objektu
2) stabilita + bezpecnost
3) je to cistsi design, takovy OS nerozlisuje komponenty na "aplikacni" a "kernelove", je jenom jeden druh
Prikladem syntaxe symbolicky zapsaneho java bytecode muze byt vystup disassembleru javap. Proste opet zjednodusene mapovani mezi symbolickymi a binarnimi instrukcemi je 1:1. JIT nebude 1:1
http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/javap.html
http://www.hio.hen.nl/~vanleeuw/pse/spanje/jasm.html
http://mrl.nyu.edu/~meyer/jasmin/about.html
-
PaJaSoft (neregistrovaný)Myslim si, ze s vetsinou zde uvedenou bych mohl souhlasit (rozchazet se zrejme budeme v tom, co je v NT podani kernel (kde je jeho hranice, napr. GUI BYLO (samotny MS to tvrdi) integrovano do kernelu z duvodu rychlosti...)) - ja to vidim tak, ze minimalne vse co bezi v rank 0 - na x86 architekture), dekuji za odkaz na Jasmina - neznal jsem - ano to bych za prekladac assembleru dokazal oznacit - byt syntakticky nepodobny x86 notaci - vychazi to z toho, ze JVM je zasobnikovy automat a jeho instrukce jsou trochu neco jineho nez poskladane NANDy, NORy, NEGy do logickych celku...:-)
Myslim si, ze je to vhodna tecka teto diskuse.
-
Petr hwsoft Lascak (neregistrovaný)No take muze byt, v assembleru jsem uz udelal nekolik velkych projektu, cca 250-300 kByte zdrojoveho textu, 50kByte programu.
Pro nejakeho C++ kare asi nic moc, ale muj software ridi komunikaci napr. v prazskem Metru a hlida vznik pozaru.
Tady by sice jeste mozna po vetsim HW zasahu slo pouzit Cko, ale jinak bez uprav uz nic jineho nez asembler ne.
Kolega psal pro tuto jednotku konfiguracni program v TurboPascalu pro DOS. Ne ze by to neslo v necem jinem, ale dulezita byla efektivita.
Navic je IT dost siroky pojem, mame tu od WORDovych tvoricu webu, pres programatory ERP aplikaci az treba k programatorum firmware pro panenku co umi mluvit a curat (prekvapive narocne).
Zatimco pro prvni skupinu zacinaji tezke casy dalsi dve jsou v pohode. -
PaJaSoft (neregistrovaný)A vite, ze se muzete seredne mylit... Vim, trva to uz nejakou dobu, ale rekl bych ze akcelerace je citit a je patrna... ano mluvim o platforme/technologii Java - ostatne prave k tomu, co pisete (a kde se puziva zatim zejmena ciste ASM) byla puvodne urcena - Web v te dobe neexistoval - protoze vyvoj zpusobem, jak pisete je sice mozny (a zrejme dneska jeste jedinny mozny), ale je to sileny vopruz... - podobnych veci jsem se ucastnil drive za a pred studiemi, takze si myslim, ze trochu vim o cem mluvite...
Muzete namitat, ze to jeste potrva, zrejme ano, ale trend je zretelny, muze se nam to nelibit, ale proti proudu jit nedokazete ani Vy... povime si za 5 az 10 let, ju?
-
. (neregistrovaný)Kvalitni vec se da napsat i 'jen' v PHP+MySQL... naprosto priserna vec se da napsat i v Jave... nezalezi na tom, v jakem jazyce kdo pise, ale na tom, jakou myslenku do sve prace vlozi - to je jako byste ohrnoval nos nad Madary, ze umi 'jen' madarsky, zatimco Vy mluvite cesky a jste tedy neco vic...
-
Michal Kubeček (neregistrovaný)Liší se především tím, pro jaké úkoly jsou určeny. Proto většinou nelze řici, že by některý byl a priori horší; nanejvýš je méně vhodný pro konkrétní úlohu. PHP a C++ jsou rozdílné jazyky, ale nemohu říci, že bych některý z nich považoval za lepší. Na něco se hodí více jeden, na něco jiného druhý. Dokonce i takový Prolog nebo LISP může být pro konkrétní projekt ideální volbou...
-
PaJaSoft (neregistrovaný)A taky ano - znate nejakou dnesni "moderni" hru, ktera ma nejakou formu AI a neni tato AI napsana v necem alespon se vzdalene podobajici Lispu?
Ono je i neco spravneho na nazoru, ze proceduralni jazyky nas velmi zkazily a ze kdyby jsme se venovali od zacatku funkcionalnimu programovani - coz je lidskemu chapani daleko blizsi (a to vcetne netechniku) - tak by mozna urcitou dobu byl vetsi hlad po vypocetni sile, ale dneska by to vypadalo jinak... - vemte si, jak stoup vykon HW za poslednich 10 let... - vite jak dneska suprove behaji Win3.11... - myslite si, ze tech technickych novinek je v tech OS podstatne vice, aby se ospravedlnilo to zabiti hrubeho vykonu na srovnatelnou uroven pred 10 lety?
-
. (neregistrovaný)Obtizne vyjadrena myslenka je spatne vyjadrena myslenka, protoze je pro nekoho jineho celkem logicky obtizne pochopitelna... pokud neco vyjadrim jasne a jednoduse, tak mam z toho vetsi uspokojeni, nez pokud je to nejaky zasmodrchanec...
Proceduralni jazyky (pocitam, ze sem nebude chtit nekdo tahat LISP a podobne specialitky) maji nekolik zakladnich konstrukci, ktere vychazeji z teorie (proste if-then a spol.) a jedine, v cem se lisi, je zpusob zapisu a "pridavne" veci, jako API, mira OOPizace ;-) a podobne... muzu klidne "umet" syntax 20 jazyku, znat jejich API, ale pokud neumim pouzit ty zakladni konstrukce k vyjadreni one myslenky, tak je je mi to k nicemu... a prave pouzivani tech zakladnich konstrukci je pro me osobne podstata programovani... -
fernet (neregistrovaný)A jeste bych dodal, ze potrebuje jistou miru znalosti takove te veci nad kterou casto ohrnuji "programatori" nos -MATEMATIKY. Je to sice slozita veda, ale opravdovy profesional si prvne overi resitelnost, spocita a hlida slozitost .... Takove veci jako teorie grafu, automatu atd. nejsou jen tak k nicemu. Turing a jini fakt nebyli hlupaky... Takze si pani programatori zakupte skripta a ucte se. Bez matematiky NENI, opakuji NENI programator profesionalem. Pokud na to nemate hlavu nebo sicflajs, tak se bezte zivit necim jinym... treba byt nezavislym poradcem...
-
fernet (neregistrovaný)Ja taky. A vzdycky si na nich rad zopakuji skolni znalosti, ktere jim chybi.... To je pak krasnej pohled na protazenej ksicht nejakyho "nezavislyho konzultanta v IT/telekomunikacich" kdyz mu pred nastoupenou jednotkou sefu na flipchartu dokazu, ze jeho "rada" je hloupa nebo neresitelna. Zejmena konzultanti s VSE maji tendenci moc zvanit a malo vedet....
Add - zdrojak MS-DOS. Kdysi davno me to kvuli necemu zajimalo, tak jsem to disassembloval a hledal pozustatky po puvodnim prekladaci. Nasel jsem ASM, nekolik ruznych C, Basic, pravdepodobne jeste Pascal, ale nic dalsiho. Verze, pokud si pamatuju - 3.3 a 5.0. -
Roman "Dagi" Pichlik (neregistrovaný)Proboha kdy uz se konecne naucime delat rozdil mezi programatorem a analytikem. Mezi temito dvema profesemi se v Cesku nedela takrka zadny rozdil jak platovy tak profesni a pritom se jedna o jabka a hrusky, ktere se jinde mezi sebou nemichaji! Rozdil je stejny jako mezi informacnim architektem webu a tim kdo to prepise do HTML.
