>>> Právě důmyslný silný typový systém a zakázání automatických konverzí je cestou k rychlejšímu, levnějšímu vývoji bezpečnějších a spolehlivějších aplikací.
Hrozne by me zajimalo, jestli krome Vaseho FTP serveru existuje nejaka dalsi success story z posledni doby a na "bezny" problem (ne raketoplan), ktera by podporila tohle tvrzeni. Proc se tedy jazyky tohoto typu (ADA, Eiffel aj.) nepouzivaji vic? Neni lepsi proste vic testovat?
Osobne souhlasim s autorem ze silna typova kontrola uz pri prekladu usetri obrovske mnozstvi problemu za behu. Jsem programator v Jave a mame to tam taky ;-)
Testovat hotovou aplikaci je prilis pozde... Pokud jste mel ale na mysli ke kazde tride udelat jeji testovaci tridu, pak je to jiste jeste o neco lepsi... ;-)
>>>silna typova kontrola uz pri prekladu usetri obrovske mnozstvi problemu za behu
To by me zajimalo, co by na to rekli programatori ve smalltalku ;-)
>>>Testovat hotovou aplikaci je prilis pozde
Ja jsem prave myslel takovy ten klasicky doporucovany postup Unit testing - Integration testing - System testing.
My zase vyvijime v C#, takze to bude velice podobne jako ta vase Java, ze, ja jsem se nad tim ted zamyslel asi trochu moc obecne, spis ve vztahu k tomu Eiffelu a tem jejich constraints, co muzou definovat v metodach a zajistovat tim integritu parametru a buh vi ceho.
Ja s tim (=kontroly) osobne mam totiz spis takovou negativni zkusenost, ze ty kontroly jsou stejne jen tak kvalitni, jak kvalitni je kod, ktery maji testovat. A casto to pak muze dopadnout tak, ze se stravi 2* tolik casu a ty constraints jsou pak stejne k nicemu, protoze neodchyti vsechno :-(
Eiffel nema constraints :-) eiffel ma design by contract :-) Je to fantasticka vec zejmena pokud uz nekdo ty klasy napsal pred vama a vy je musite pouzivat coz jsou typycky standartni klasy dodavany s kompilatorem. Usetri to spoustu casu s ladenim. Sam to taky pouzivam, protoze je to super a hlavne protoze muzu klidne zahodit debuger, kterej podle me jen zdrzuje, protoze clovek pak pise metodou pokus omyl a vetsinou tech omylu je pozehnane nez prijde spravny reseni.
Pokud je nekdo linej proste nemusi vsechny ty require a ensure kousky psat. Jeho rozhodnuti :-)
Ale hlavne Eiffel je objektove orientovanej jazyk narozdil od javy c# c++ a podobnejch bazmeku... tj zadny primitivni typy, multinasobna dedicnost, zadny pointry, zadny zkurv... interfejsy, ktery vyvoj ztezujou nez by ho zlehcili, garbage colector a milion dalsich krasnejch veci.
S eiffel vs java/C#/c++ apod je to jako s francouzkska kuchyne vs mcdonnald. To prvni je super a spousta lidi nevi jak dobry to je, to druhy je sracka ktera ma nejakou garantovanou mizernou kvalitu ale dostacuje to vetsine
>>> eiffel ma design by contract :-)
Ja vim, me se jen po ranu nechtelo premyslet, jak se to doopravdy jmenuje ;-)
Je to pravda, porad je to vlastne dokola (i v jinych prispevcich): kdyz to bude psat nekdo dobre, tak to bude dobre, kdyz ne tak ne. Ted jde vlastne jen o to, jak vsechny kolem co nejvic donutit, aby to dobre psali. A v tom mi ty testy prijdou jednodussi, protoze si je aspon muzu poustet porad dokola a divat se, jak dopadly.
>>>clovek pak pise metodou pokus omyl
Tak to je uplna pravda, programovani typu "Aha, tak ono i je 0 a melo byt jedna, tak to tam asi ma byt i++;" je asi to nejhorsi co znam. Ale v tomhle zadny jazyk, ani Eiffel, nepomuze, ne?
A bude teda aspon nejaky naznak te success strory v Eiffelu? ;-)
Proč se tolik dělá v C/++ jsem nikdy pořádně nepochopil. Plain C je výborný prostředek na low-level programováni (jádra OS), proč se v tom dělají kancelářské balíky nechápu. Ada je IMHO na servery jako dělaná. Vemte si například kolik se dělá patchů kvůli různým buffer overflow. U jazyke, který pořádně kontroluje meze polí takový útok nepřichází v úvahu. Maximálně jedno vlákno serveru sletí na nějaké výjimce, ale ostatní uživatelé frčí dál.
Jinak Ada má zase své problémy. Nepříjemná práce s řetězci a neuveřitelně toporné OOP (bez rozhranní, jednoduchá dědičnost, nepřehledná syntaxe).
> Neni lepsi proste vic testovat?
Ale to je právě ono! Překladač silně typového jazyka vlastně provádí část testů sám, takže je není nutné implementovat znovu a znovu a znovu...
> Proc se tedy jazyky tohoto typu ... nepouzivaji vic?
Ada je moloch. Sám jazyk obsahuje konstrukce pro "úplně všechno", např. nízkoúrovňové I/O či synchronizaci paralelních procesů. IMHO v době jejího vzniku nebylo snadné udělat překladač, navíc takový aby se vešel na tehdejší HW, takže existovaly jen implementace přísně kontrolované US vládou. A mezitím se objevily "lepší" jazykym např. <flame>Java</flame>. ;-)
TeX není napsaný v C. Primárním zdrojákem je jeden soubor velikosti cca 1 MB, ze kterého lze pomocí nástrojů tangle a weave vygenerovat zdroják pro překladač (v Pasaclu ?) a referenční příručku (v TeXu). Vstup pro překladač se automatizovaně převádí do jazyka C.
Aspoň dříve to tak nějak bylo.
Pouzivani tech ci onech jazyku je, podle meho nazoru, zalezitost mody. Chvilku leti Delphi nebo Kylix, pak najednou C++ nebo Java a vlastne se pouziva vsecko... a je v tom proste gulas :-)
Pravda ale je ze, je pomerne dulezite, ze je z ceho si vybrat. Silnou typovou kontrolu jiste oceni programatori, kteri ji vyzaduji.
Syntax to ma nadhernou. A nadherny je ze se jmenuje po zene, prukopnice programovani a "prave ruce" konstruktera prvniho (i kdyz tusim jen navrhu) mechanickeho pocitace.
Takze zaverem snad jen live long and prosper a uzivejte ADY podle nejlepsiho vedomi a svedomi.
ADA zadna moda neni a nikdy nebyla. ADA je proste pro nektere aplikace temer nutnost (i kdyz jak kde, u nas se casto i mission critical aplikace placaji v delphi a za neocekavane vypadky ve vyrobe nejen ze dodavatel neplati, ale naopak si nauctuje dalsi palky za udrzbu). Nekdy ADA nutna neni (treba ten ftp server), ale urcite by mnoha aplikacim prospela, protoze jaksi implicitne vece k bezpecnemu navrhu. Pokud se tedy ADA stane modou, muzeme na tom vsichni jen vydelat :-)
Moda neni pouzivani tech ci onech jazyku, moda je mluveni o nich.
Jinak v praxi je to spis tak, ze na vetsi projekty se v 60% pripadu stejne pouziva C++ - proto je taky takovy otloukanek, vsichni tvurci tech "dokonalych" jazyku proste zavidi :)
Jinak ADA me prijde jako typicky neprakticky slepenec, jaky muze vzniknout jenom na objednavku ministerstva obrany v ramci zadanych terminu. Proti Jovialu z toku 1960 (ktery nahradila) je to ovsem asi pokrok :)
No, já mám pocit, že jsou stálice, pár dočasných hvězd a pak minority.
Takové C/C++ je poměrně stálice, a to už přes 30 let. Ten jazyk má výhodu, že v něm napíšete všechno, co v jakémkoli jiném vyšším jazyce a ještě leccos navíc. V tomto jazyce se píší operační systémy, i spousta programů.
Java se jeví jako další takovou stálicí.
Placas nesmysly "kokot"-e!
Pro procesory podle Mil.Std.-1750B jiny prekladac nez assembler a ada snad ani neexistuje a vsechny satelity, ktere vypousti ESA (European Space Agency) nesmi snad ani na palube mit SW psany bud v assembleru (pak ale nasleduje silena procedura overovani kodu na emulatoru a to UPLNA!!! [overit vsechna vetveni]), nebo v ade.
Ja jsem v ade odmital psat, tak jsem navzdy uviznul v "base segmentu" s jeho C na OpenVMSu (platforma uVAX pozdeji Alpha) :-)))
FORTRAN-4X byl moc fajn, zato FEL Pascal umel akorat zaplacat LG-stopy a premenit RT-system v RT-konzumujici system ;-)))
Taky si jeste pamatuju, jak jsme vzdycky rikavali: "Vite jak bude vypadat nejpouzivanejsi jazyk v roce 2005?"; "Nevim, ale bude se jmenovat FORTRAN!" :-)))
To presne podle me vyzdvihuje nevyhody fortranu:
- ve verzi 2 nemel ani logicke IF-y
- ve verzi 4 a (4X - to bylo jen vylepseni od HP...vic prikazu na radek dokonalejsi I/O konverze) chybelo temer vsecko, co maji moderni jazyky... prace s dynamickymi promennymi, prace s retezci, logicke operatory.....
- ve verzi 85 (snad GNU... uz to nesleduju) byly pridany i bloky programu (odstranilo to pracna navesti -> "opravdovy programator napise 5 stran kodu a pak bezchybne napise navesti: :-)))
.... a tak by se dalo pokracovat dal
shrnuto: syntaxe FORTRANu se neustale vyvijela, ale nazev FORTRAN porad ZIJE!!!! :-)))
Ja psal ve Fortranu tusim 90, kterej mel procedury, blokovy prikazy a vsechny dalsi vymozenosti (aspon teda pokud si vzpominam, je to pres deset let), takze sem se cejtil celkem pohodlne.
U nas se zas rikalo:"Opravdovy programator programuje ve Fortranu v jakemkoliv programovacim jazyku".
No, ono kdyby v cecku byla nejaka rozumna (a pouzivana) knihovna na retezce, tak by podle mne bylo o polovinu chyb mene... Zlaty PHPkovy/perlovy/... retezce, u tech se tezko stane, ze by praci s nima clovek by tvoril diru :-)
Jinak ale ADA neni samospasitelna nebot neexistuje jazyk, ve kteme by se nedal napsat spatny program (viz odpurci OOP, ktery dokazuji ze OOP je k nicemu tim, ze to v nem jde) :-))
A mimochodem - je chranena treba i proti chybam typu "printf"?
Pokud mě paměť neklame, existovala ADA už v 70. letech. (Počátkem 80. let získala ISO normu). Tehdy byla považována za nejdokonalejší jazyk spolu s PL/1. Ale PL/1 byla součástí systému IBM a tak se ADA používala pouze na počítačích jiných výrobců, proto tak malé rozšíření. (K nám prakticky nepronikla). Jenže šílený devítiprůchodový kompilátor PL/1 se ukázal jako totálně nepřenosný a ADA má snad volné pole - není-li pozdě. Mimochodem - v těch dobách se (u těchto jazyků) použití debuggeru považovalo za něco beznadějně zastaralého a směšného a vážně to nebylo za potřebí, protože na chytání chyb byl kompilátor. Jinak co se týče těch družic - pokud je někdo takovej blbec (Lockheed), že počítá ve stopách a pak je zapomene převést na metry - nepomůže ani ten nejlepší jazyk.
Ještě maličkost - GNAT není kompilátor ale translátor ADA->C.
>Ještě maličkost - GNAT není kompilátor ale >translátor ADA->C.
Není pravda. GNAT rozhodně negeneruje žádný céčkový kód, který by se dál parsoval atd. Naopak překlad celkem rychlý. GNAT překládá do mezikódu, ze kterého nějaká vrstva GCC vyrábí stroják. (Existuje i JGNAT, který generuje Javy bytecode.)
V uvedeném případě byl program testován jistě dokonale, pouze se jaksi nepočítalo s tím, že data dostává v jiných fyzikálních jednotkách - dokud se sonda nerozbila o povrch Marsu. Je to příklad toho, že nelze dělat spolehlivé a bezpečně programy, pokud jsou firemní nebo místní zvyklosti důležitější, než mezinárodní normy. (Co mi to jen připomíná?)
Vestinu s typovych cachru umi Object Pascal taky (vcetne kontroly intervalu a varovani pri mixovani typovych a netypovych promennych) a umi toho mnohem vice (a to nemluvim o OOP).
ohledne weboveho serveru:
http://www.ritlabs.com/tinyweb/
(vicevlaknovy web server se zdrojovymi texty, Object Pascal, velikost exe - 53 kb, zadne dalsi knihovny)
Proc pouzivam Object Pascal?
Dava mi silu (skoro) jako C, umoznuje mi psat rychle, citelne a prehledne a kontroluje mne abych nepsal prasacky kod (vyjimky, property). Zadne preteceni buferu (pokud to vylozene nevynucuji).
Ve spojeni s IDE mi dovoluje byt nekolikrat efektivnejsi pri programovani nez v jinych jazycich.
Viz. muj Seksi Commander, kde se kazdy muze podivat do zdrojaku :), nebo muj serial na rootu.
Object Pascal je výmysl od Borlandů. Neříkám, že je špatný, ale není to žádný normovaný jazyk. Samotný standardní Pascal byl spíše zamýšlen jako jazyk na učení se programování, než jako jazyk pro praxi. Standardní Pascal prakticky ztrácí dech a už používání souborů je jen tak tak.
Další vývoj Object Pascalu je až příliš závislý na firmě Borland, a to je pro mě dostatečný důvod, abych Object Pascal používal jen tehdy, pokud je to vysloveně vyžadováno zákazníkem, a nebo na projekty s jepičím životem bez perspektivy delšího trvání.
Já jsem dělal jako nadšený pascalista několik let, a když jsem poznal C, tak jsem prostě přehodil veksl, a zatím jsem nikdy nezalitoval. Toto je ovšem spíše o mých osobních preferencích.
Ze všech jazyků, co jste vyjmenoval jen OP nemá žádnou normu jazyka. Pokud Vás OP zaujal natolik, že je Vaším favoritem, klidně v něm programujte.
Java má mnoho firem, kteří pro něj vyrábějí runtime, kompilátory, vývojová prostředí. To samé lze říci o C, o C++, o Fortranu, atd..
C# je nový jazyk, který ale má svou normu. IMHO se tak trochu čeká, jak se tento jazyk ujme. Ale už existuje kromě MS také free projekt.
OP žádnou normu nemá. Je plně v libovůli, co s jazykem Borland udělá. OP dělá jen Borland a FreePascal. Žádná jiná firma, pokud alespoň vím, nevyrábí kompilátor pro OP.
Nechápu proč se tady pořád napadáte nebo jste navzájem ironičtí za to, že ten nebo onen programuje v tomhle nebo tamhletom. Přijde mi, že jste se navzájem v životě neviděli, nemáte ani páru o pohnutkách toho druhého, sami v tom neděláte, ale víte naprosto přesně o všech slabinách toho druhého jazyka a v čem ten druhý programátor má psát. Vím jen že pro programátory platí jediná věc: kolik programovacích jazyků znáš, tolikrát jsi programátorem. A tím bych pro dnešek skončil své kázání :-)
Děkuji za vjednání míru. Je v tom kus pravdy. Snad bych jen dodal, že útočím na jazyk, nikoli na člověka.
Snad bych jen upřesnil, že v OP jsem byl nucen dělat více, než je zdrávo, a rozhodně jsem si ho jako jazyk neoblíbil. Možná ani ne tak kvůli jazyku samotnému, který zase není až tak zlý, ale kvůli přístupu firmy Borland. IMHO programovací jazyk nedělá ani tak syntaxe a možnosti, jako jeho základní knihovna. A jako celek, tj. jazyk OP a základní knihovna nad něj působí dost nekonzistentně, jakoby jedno bylo nalepené na druhé.