Názory k článku Parser bankovních výpisů aneb hrátky s Ragel
Přidat názor
-
rawww (neregistrovaný)Bud jsem degenerat ja - nebo pan, ktery pise tento clanek.
Mam-li string "nevimjestli jsemdegenerat" a potrebuji-li z nej delat Excel megatotalfatalbrutal soubor.xls myslim, ze staci odstranit mezeru zpusobem:
cat soubor.xls | sed "s/\ //g" a vystup z terminalu si treba poslat postou na Kubu.
Nebo muzu pouzit RoR ToT FmM a pajpit to do Win2009Server a pres Javu to prdlat v XUbuntu a pak to dam pres bajbu do kose a vysypu ho.
Dekuji za pozornost.
P.S.: velice se omlouvam byl jsem schopen to docist pouze do tretiho odstavce - nebo kamsi nekam tak
ego@easy.cz -
No pro mne to byl problém. Nemohu však tvrdit, že znám regexpy a sed nějak dokonale. Bez kontextu ovšem nepoznám, zda "3 449" je textové pole, ve které mezery nesmím odstranit (protože jsou významné), nebo číslo 3449. Akce, které Ragel umožňuje přiřadit různým přechodům automatu, mi umožní požadovaný kontext jednoduše získat (mohu např. čítačem sledovat, které pole v pořadí zpracovávám a dohledat jeho popis a tím i požadovaný datový typ). -
rawww (neregistrovaný)To si snad uz ze me vsichni dneska delate legraci. Nejenom ze jsem musel cekat kvuli nejake slavii nebo co to je 20 minut na autobus, ale jeste opet vidim cloveka, ktery je schopen psat kod "CESKY!". Tak toto uz je moc i na mne. Odesel mi stroj musim to v singleusermode pres mount -a s warningama scpeckovat vsechno na novy a tech 200GB od zakose me nebavi natolik abych neprudil. Jeste jednou se omlouvam za sve reci, ale toto mne bavi. ;o)
eGo@easy.cz -
Stejně mne od toho nakonec odradily technické problémy. Jednak používám různé textové editory a některé na začátek souboru vkládaly BOM. Pokud si dobře vzpomínám, tak Ruby v tom případě protestovalo (jiné jazyky obvykle také).
Další problém byl, že ve standardní konzole Windows XP (cmd.exe) nešlo pořádně vypsat UTF-8. Nebo se mi to alespoň nepodařilo. Kódová stránka UTF-8 tam sice nastavit šla, ale při pokusu o výpis UTF-8 to spadlo. Ještě že command-line klient PostgreSQL (psql) umí výstup překódovat do CP1250 :-).
Jinak UTF-8 v názvech proměnných čeká jistě velká budoucnost. Spočítejte si např., kolik toneru by ušetřila laserová tiskárna při výpisech zdrojáků, kdyby názvy proměnných byly např. čínsky - tedy jen jeden nebo dva znaky aniž by se ztratil význam daného jména. Počítám, že nejpozději do dvou let vznikne nějaká direktiva EU, která z ekologických důvodů bude délku názvu proměnných nějak omezovat. Pak nám ani nic jiného nezbyde :-) -
To nevím, jak je to s UTF-16, zas do toho ve Windows tak nevidím. Ale když si spustím cmd.exe, tak má (alespoň u mne) pro výstup nastavenou kódovou stránku 852 (tj. microsoftí starý "Latin 2") a vypisuje správně jen texty s tímto kodováním. Když tam nastavím TrueType font Lucida Console a přepnu si kódovou stránku na 1250, tak to bez problémů vypisuje texty s kódováním 1250. Když jsem tam zapnul kódovou stránku pro UTF-8 (tuším 65001), tak se to tvářilo v pořádku, ale když jsem tam spustil klienta s tímhletím kódováním, tak to spadlo na nějaký "Out of Memory" nebo co.
Každopádně nechápu, nač jsou pro konzolu potřeba konverzní tabulky pro UTF-8, když běžné okenní programy si s UTF-8 rozumí bez problémů. -
Vysvětlím. Windows řady NT pracují komplet v Unicode UTF-16. Znaky jsou vždy typu 16-bitového wchar_t, a nikdy 8-bitového char. Na konzoli se provádí výstup přes volání WriteConsoleW.
Historické Windows 9x a 3x měly ovšem API v ANSI code page, s datovým typem char. Proto i Windows NT z důvodu zpětné kompatibility nabízejí volání pro 8-bit znaky typu char. Tato volání končí na A (WriteConsoleA). String se převede z kódové stránky do UTF-16, zavolá se wide verze volání, a poté se případně převede výsledek zpět na chary. V případě konzole máte možnost nastavit, z jaké kódové stránky se budou stringy převádět do Unicode (hint: kašlete na to, a jeďte v UTF-16, jak autoři zamýšleli). K tomu musí ale systém mít nainstalovanou konverzní tabulku. Shodou okolností existuje i tabulka pro UTF-8 (a v XP asi není by default nainstalovaná), jakkoliv NT konzole nikdy UTF-8 podporovat neměla.
Dalším problémem jsou samozřejmě fonty. Pokud jede konzole v Unicode, ale font nemá Unicode znaky (ten defaultní je nemá), provede se konverze do code page fontu. Pokud nastavíte na konzoli font Lucida Unicode, bude zobrazovat ten subset Unicode, který Lucida Unicode nabízí (s japonštinou u tohoto fontu nepočítejte, azbuka tam je).
Historicky je v SDK ještě možnost kompilovat Unicode či ANSI verzi aplikace. Typ TCHAR se mapuje by default na 8-bit char (použilo by se pro Win9x bez Microsoft Layer for Unicode). Pokud definujete symbol _UNICODE, mapuje se TCHAR na 16-bit wchar_t (cílem jsou Windows řady NT). Obdobně funkce tcslen() se mapuje na strlen() nebo wcslen().
Vy jste zvyklý psát aplikace pro unixy. Na unixech je situace jiná. Glibc používá znaky typu char (wchar_t jen pro locale-enabled volání, kterých je pár kusů), a nikdo ani neví, jestli API zrovna krmíte UTF-8, 8859-2, 8859-5, nebo něčím jiným. To může vést třeba k tomu, že budete mít názvy souborů na disku pomíchané v UTF-8 a 8859-2. Každopádně pokud se snažíte psát aplikaci pro Windows tak, jak jste zvyklý jí psát pro unixy, budete asi používat znaky typu char, a tedy volat volání končící na A, určená pro Windows 9x. Unicode v takovém případě dostanate velmi těžko (nastavení code page je pro mnoho oblastí system-wide).
Závěr: pokud píšete pro Windows, stringy jsou vždy tvořeny znaky typu wchar_t, a výstup na konzoli provádějte pomocí WriteConsole, nebo wprintf. Pokud trváte na typu char, vzdejte Unicode, nebo se připravte na problémy.
Ještě reference:
http://msdn2.microsoft.com/en-us/library/ms776442(VS.85).aspx --- Unicode in the Windows API
http://msdn2.microsoft.com/en-us/library/2dax2h36.aspx --- MFC a Unicode
http://msdn2.microsoft.com/en-us/library/c426s321.aspx --- Generic-Text Mappings in Tchar.h
http://msdn2.microsoft.com/en-us/library/ms682010(VS.85).aspx --- Character-Mode Applications
http://www.metagraphics.com/index.htm?page=pubs/mgct_language-portable-code.htm --- něčí souhrn -
segur (neregistrovaný)Pokud se na reprezentaci znaku používá 16bitová hodnota, tak to může býl leda UCS-2 (schopné reprezentavat prvních cca 65 tis. znaků Unicode), těžko UTF-16, které má variabilní délku 2 nebo 4 bajtů (a může tedy reprezentovat plný Unicode rozsah). Druhá možnost je, že jsem to pochopil špatně a Windows používá na uložení každého znaku buď jednu nebo dvě hodnoty wchar_t.
-
Rejpal (neregistrovaný)
Á, UTF-16, to je ta vyvážená kombinace paměťové úspornosti, endiánové nezávislosti a skvělé kompatibility s ASCII a C, které UTF-16 převzalo z UCS-4/UTF-32, a algoritmické jednoduchosti UTF-8? :o)
V mailing listu IETF jsem zahlédl tenhle postřeh:
"In a local file store, UTF-16 has some questionable advantages. Over the wire, it just decreases significantly the probability of interworking. The IETF and the UNIX operating system community had it just right when they chose to standardize on UTF-8 based interfaces."
A to je, prosím, od lidí, co nám schvalují internetové standardy, jako je TCP/IP a podobně. Osobně myslím, že ideální stav je mít v paměti UCS-4 a na disku/na síti UTF-8.Ovšem i u toho UCS-4 v paměti bych ještě byl s hodnocením opatrný. Člověk s tím sice získá indexaci znaků (no, spíš "znaků", co do praktického významu) řetězce v konstantním čase (kterou s UTF-16 obecně rozhodně nemá), ale pořád ještě tu jsou i v UTF-32 kombinující sekvence, které hatí indexovaný přístup k "logickým" znakům tak jako tak. Jestli se nepletu, spousta precomposed znaků prostě neexistuje, a první komponovaný znak zabije konstantní časový přístup ke komponovanému grafému. Přitom kodér a dekodér UTF-8 je tak triviální, že nestojí skoro žádný strojový čas, rozhodně ne v porovnání s šířkou pásma paměti, disku a sítě. Takže je sporné, co je vlastně rychlejší.
Dnešní doba díky hiearchii pamětí čím dál tím víc favorizuje kompaktní datové struktury, a v praxi je celá řada užitečných operací v UTF-8 pomalejší oproti UTF-32 v závislosti na velikosti reálných dat jen o tu konstantu, pokud není rovnou rychlejší kvůli kompaktnosti, a bůh ví, jak i poměrně normální operace typu délky řetězce ve znacích degenerují i na UTF-16/32. (Co třeba kanonická ekvivalence znaku U+216A a sekvence U+0058 U+0049? Nemusí to být jen diakritika...spousta zdánlivě stejných řetězců snadno může být "různě dlouhá", aplikací tradičního principu "spočítal jsem tu délku špatně, ale zato rychle". :o) U lineárního skenu ale může mít UTF-8 značnou výhodu, pokud je v něm daný text kompaktnější. To sice není zaručené, ale ve značné části světa to nakonec platí. A do přenosů dat na síti se aspoň nemotají ti odporní indiáni, což ocení každý technik. :-)))
-
Lael Ophir (neregistrovaný)UTF-16 je kompatibilní s C. Navíc zpravidla uvažujeme UCS-2. UTF-16 se týká jen velmi omezené oblasti, a ani tam se ještě neprosazuje (japonci vzpomínají na MBCS, a hrozí se). UTF-8 má pár problémů. Vlastní kódování samozřejmě přináší jistá omezení, ale s implementací na unixech je to ještě horší. Pánové přemýšleli, jak za co nejméně peněz dostat Unicode do systému. Řešením je prostě cpát UTF-8 skrz API pracující s chary. Bohužel v systému mohou zároveň pracovat aplikace v historických code pages (třeba 8859-2, 8859-5) i UTF-8. A protože API ignoruje, odkud string přišel (s výjimkou locale-enabled volání, kterých je pět a půl), vzniká zmatek. Na disku se mísí názvy souborů v 8859-* s UTF-8; UTF-8 based aplikace ty názvy pak nemusí rozdýchat, protože jde o neplatné UTF-8 sekvence. Předpokládám, že podobné problémy má clipboard, a řada dalších věcí. A samozřejmě (g)libc implementuje řadu funkcí typu "najdi znak ve stringu", kde znak je char, takže funkce třeba s azbukou prostě nepůjde (ježto UTF-8 sekvence pro znak v azbuce je více charů). To se elegantně vyřešilo tak, že se u funkcí změnil popis, a nyní nehledají znaky, ale byte. Problém fakticky nevyřešen, ale dokumentace je formálně bezchybná :).
Pěknou věcí je také rozeznávání, zda je soubor v Unicode, nebo ne. Unicode consorcium doporučuje používat Byte Order Mark. Jenže programy, které na UTF-8 nejsou stavěné, s BOM zápasí (shelly, PHP, Opera a další). Takže se na unixech BOM zásadně nepoužívá. Výsledkem je, že nikdo neví, co je v UTF-8, a co v národní code page. Ai na úrovni názvů souborů (viz výše), ani na úrovni obsahu textových souborů. Ve výsledku nelze rozeznat shell skript či konfigurák v UTF-8 od toho v 8859-*.
Glibc exportuje pár funkcí i v UTF-32. Zajímavější ale je, že například Qt používá UTF-16. V rámci každého volání pak dochází k překladům na UTF-8 či UTF-32, a zase zpět na UTF-16. člověk neví, jestli se smát, křičet, nebo bušit hlavou o zeď.
Když se na to podíváme, tak asi nelze než říci, že implementace Unicode na unixech se nějak nepovedla. Skoro by se chtělo říci, že starého psa novým kouskům nenaučíte.
Operace nad stringy typu třídění, porovnávání apod. jsou vždy pomalé, pokud do věci zapletete locale. Bohužel, je to nutná daň za korektní podporu národních jazyků. -
anonymnímyslim, ze je mozne ze spravne neodhadnete budoucnost sveho projektu...
pokud jej zacnete psat cesky muze byt v hlubohe budoucnosti hodne tezke najit nejake zahranicni kolegy-spolupracovniky. ...treba...
odstrasujicim prikladem budiz treba ten sql server od 602software. v te dobe kdyz jej zacali psat, bylo taky celkem v pohode mit v tom ceske texty...v te dobe bylo naprosto nezadouci posilat kod do sveta... a ted jsou v ... tezke pozici :) -
Keny (neregistrovaný)Zcela vás chápu. Je však rozdíl mezi větším projektem a drobnou, jednoúčelovou utilitkou jako v tomto příkladě. Měl jsem tedy alespoň pocit, že pisatel chtěl pouze demostrovat použití parseru Ragel.
Pokud jde o komentáře, tak já jich využívám především k poznámkám, takže je pro mne důležité aby byly primárně srozumitelné pro mne. Tak proč se v nich pokoušet o eseje v angličtině. -
Rejpal (neregistrovaný)Připomněli jste mi můj oblíbený komentář na Slashdotu:
:-D - doporučuju přečíst celé. ;-)Office worker: "why does Open Office take so long to load?"
IT guy: "That's because the routines were written by a German guy in his free time. I'm sorry, little-miss-everybody-should-speak-English, but this poor guy was working for free. What do you expect?"
Office worker: "what does the German language have to do with this?"
IT guy: "Your PC was built in Austin, Texas. German is its second language. See this routine here, öffnenSiediegroßeAkte()? Your American PC doesn't know what that means, and has to consult a dictionary each time it sees it. There's a group of teenagers translating it into English. They work on one word each for greater safety. One of them saw two words of the program and spent several weeks in the hospital."
-
Rejpal (neregistrovaný)Ragel se hodí na víc věcí, než jen na parsování nějakých tabulek. ;-) Třeba rubí webový server Mongrel ho využívá na značně efektivní zpracování HTTP protokolu na vstupu. Prostě HTTP 1.1 se nemění a je dobře zdokumentované, tak šup s ním rovnou do Cčkového stavového automatu. ;-)
-
Je potřeba si uvědomit, že to zadání v článku je oproti skutečnosti trochu zjednodušeno. Pokud vezmeš jen ten konkrétní formát, tak máš pravdu (až na to, že v awku se fakt blbě pracuje s třídou ActiveRecord z RoR - asi bych z toho musel generovat přímo SQL pro Postgres, což by ale nebylo úplně ono, protože bych neměl průběžné kontroly - např. u čísel protiúčtů, navíc bych asi musel poznávat datové typy - nevím, zda to jde v awku - moc ho neumím). Krom toho ty výpisy byly i historické - formát se čas od času trochu měnil, takže v tom zpracování byla i nějaká "business logika".
No a nakonec, pokud bych ten parser v Ragelu bral jako východisko pro trochu obecnější parser obdobných souborů, tak mi to pořád celkem příjde jako krok rozumným směrem. Když si napíšeš regulární výrazy pro trochu obecnější CSV - třeba že v hodnotách polí mohou být escapované uvozovky a že některé hodnoty nemusejí být uzavřené do uvozovek, tak se mi zdá, že výsledné reguláry budou, no, hnusné. -
Plague (neregistrovaný)Inu hnusné, ale není potřeba se učit obecnější nástoj, když současné postačují celkem dobře...
Chapu, že ten jzyk se dá použít na obecnější věci a asi se dá použít dobře, ale prostě instalovat a učit se a skriptovat parní lokomotivu kvuli takovém uzadání, je podle mě docela blbost.
Chybně vybraný příklad a jaké pohoršení to způsobilo co? :) -
Mně osobně se napříkald pracuje s komplikovanými regulárními výrazy dost špatně - hlavně co se týká hledání chyb a relativně malé flexibility. Mám radši nástroje, jejichž výrazové prostředky mi dovolí rychle se zorientovat v kódu, který jsem psal před týdnem a které mi např. nabídnou prostředky pro rychlé a pohodlné ladění. BTW, Ragel je z podobných prostředků IMHO poměrně mocný, přitom velmi "lightweight".
Rád bych ještě jednou zdůraznil, že v článku jde o zjednodušený příklad. Pokud byste to bral jako úplné zadání reálného problému, tak bych se já naopak mohl podivovat nad použitím regulárních výrazů jako nepřiměřeného prostředku. Pak by přece v podstatě stačily tři primitivní řetězcové operace: na řádku useknout úvodní a koncové uvozovky a rozdělit řádek na řetězce v místech, kde se vyskytuje ",". Na to přece regulární výrazy potřeba nejsou. :-)
-
b*d (neregistrovaný)Ale jo budiž.
Myslím, že čtenáře může článek zaujmou (i třeba nadpisem) i tím, že se docela hodí rozparzovat bankovní výpis (příjmy, výdaje, úroky) a to i tak že je blízko k daňovému přiznání a ročních uzávěrek. Teď mně zrovna napadlo, že umět něco víc než AWK je zrovna pro uzávěrku dobré (třeba: toto je účet dodavatele, toto jsou účty zákazníka atp.)
Já jsem to napsal, a promiňte jestli se vás to dotklo, rozhodně jsem tím nechtěl snižovat kvalitu článku nebo tématu, chtěl jsem napsat "potřebuješ-li parsovat jednoduchý výpis, zkus se podívat po awk".
Na druhou stanu musím souhlasit, že jednoduchý zápis pravidel je alfou a omegou, z našeho šálku kávy - mnoho projektů stále používá JavaCC (pozor ne javac s jedním c nakonci), než třeba ANTL (jestli to píšu správně). Přestože je JavaCC mrtvý (dál se nevyvíjí), důvod vidím v tom, že start-up je dalo rychlejší v JavaCC než v ANTNL. Nedostatky JavaCC si člověk uvědomí po chvíli používaní.
A jen tak naokraj ono BNF od regexů zas tak daleko nemá (myslím třeba JavaCC). -
Palo (neregistrovaný)Priklad bol asi zvoleny nevhodne. Toto som urobil rychlejsie nez som precital clanok. Pracu s jednotlivymi hodnotami group(N) uz asi zvladne kazdy. Ja tomu clanku asi nerozumiem.
__________________________________________________
import java.util.regex.*;
import java.io.*;
public class Do {
public static void main(String arg[]) throws java.io.IOException {
BufferedReader d=new BufferedReader(new InputStreamReader(System.in));
// Parse header
Pattern p=Pattern.compile("\"([^\"]+)\",\"(.+)\"");
for (Matcher m=p.matcher(d.readLine()); m.matches(); m=p.matcher(d.readLine())) {
System.out.println(""+m.group(1)+"\t"+m.group(2));
}
// Parse TX
p=Pattern.compile("\"([^\"]+)\",\"([^\"]+)\",\"([^\"]+)\",\"([^\"]+)\",\"([^\"]+)\"");
for (Matcher m=p.matcher(d.readLine()); m.matches(); m=p.matcher(d.readLine())) {
System.out.println(""+m.group(1)+"\t"+m.group(2)+"\t"+m.group(3)+"\t"+m.group(4)+"\t"+m.group(5));
}
}
}
__________________________________________________ -
Máte v podstatě pravdu, že pro soubory přesně tohoto formátu by to takhle bylo jednodušší. Ale příklad je úmyslně zjednodušen a navíc ten konečný automat z Ragelu je o něco málo obecnější, než Vaše řešení - zpracuje v druhé části libovolný počet polí. BTW, těch polí je víc než 5 - řádky ve výpisu CSV souboru jsou pro přehlednost zkráceny - všimněte si třech teček.
Vaše řešení má IMHO oproti mému ještě další nevýhodu: zkuste si (když už je to cvičení :-) ty regulární výrazy upravit tak, aby akceptovaly v hodnotě pole uvozovky (obvykle se zdvojují nebo se nějak escapují např. dvojice backslash-uvozovky). Možná, že to není složité (nepovažuji se zrovna za regexp guru), ale přesto si myslím, že úpravy tohoto typu jsou v gramatice Ragelu podstatně jednodušší. -
Jan Molič (neregistrovaný)Fakt netuším, co proti autorovi článku všichni máte. Nepoužil reguláry, nepoužil sed. Nepoužil Javu. Porušil kodex? Naopak myslím, že celkem přehledně demonstroval použití univerzálního parseru. Kolikrát člověk řešil nějaký šablonovací systém a potřeboval právě něco takového (a ne všichni se to učili ve škole, takže ne všichni vědí, že podobné parsery vůbec existují).
A vzhledem k tomu, že parsování souboru sedem může být časově náročnější, autorův přístup oceníte, zejména děláte-li hodně bankovních operací za sekundu :-) -
Lael Ophir (neregistrovaný)Psal jste, že to CSV nejde otevřít v Excelu. Proč tedy nepoužít VBA (umí pracovat se soubory, příppadně i regexpy)? Můžete výsledné makro pověsit na tlačítko na toolbaru, a můžete třeba použít XLA šablonu, do které výsledná nasypete. Šablona může mít "rozkreslené" údaje typu account number a currency, může být lokalizovaná, a výtisk dokumentu může třeba obsahovat logo banky :). Když takovou věc pošlete do banky, možná jí i doporučí klientům (což bych si u skripu v Ragelu a Ruby nemyslel).
-
Rejpal (neregistrovaný)Vzhledem k tomu, že se tyhle věci dají zabalit i včetně GUI do úhledného .EXE souboru s grafickým rozhraním, netuším, proč by někdo nemohl doporučit klientům skript v Ruby, o kterém ani nebude vědět, že to je skript v Ruby. ;-)
Navíc mě opět nijak nepřekvapuje Vaše naprostá ignorace potřeb řešitele - pokud někdo potřebuje sypat data z bankovních výpisů do PostgreSQL a nejlépe zaintegrovat tuto funkci do vlastní aplikace psané v RoR, radit mu, aby to místo v Ruby udělal v Excelu s výstupem do šablony s logem banky, je opravdu na duševní vyšetření. :o) -
Jistě se to dá napsat v PERLu, AWK nebo čemkoliv jiném. Otázka je, proč to dělat, když máte v Excelu VBA. Takhle mi to připomíná situaci, kdy lidé potřebují vypsat seznam souborů v adresáři, a shánějí kvůli tomu GUI utilitu.
Pokud si vyslíte, že z VBA nevložíte data do DB, možná je to také na duševní vyšetření. :o) -
Pomiňme zanedbatelné důvody typu, že celý zbytek aplikace je napsaný v Ruby, to že VBA umím podstatně míň než Ruby, nebo že to vlastně v Excelu ani mít nepotřebuju apod (v článku jsem tím jen chtěl demonstrovat, že ta konkrétní "CSV" varianta je mírně problematická). Ale jeden opravdu pádný důvod by se našel: nemám Excel - jen jsem to v něm krátce vyzkoušel (samozřejmě u legálního uživatele). Když už, tak bych to dělal v Calcu (abych řekl pravdu, mírně o tom Calcu uvažuju - OpenOffice má pro mé účely IMHO lepší práci s DB i reporting než MS Office - pokud už zanedbám cenový rozdíl a to, že OO je multiplatformní).
-
Pokud nemáte Excel, pak není co řešit. Typická situace je přesně opačná - Excel má na počítači v podstatě každý, a VBA umí každý pracovník helpdesku (plus power useři). OOo Calc je také alternativa. Pro mě je problém, že Calc jsem viděl z rychlíku (ani nevím, že čem se tam skriptuje), a má ho minimum lidí.
Mimochodem MS Office je také multiplatformní. A je cílovým platformám přizpůsoben lépe, než OOo (ten na Macu vypadá jako aplikace z jiného světa, na Linuxu nakonec také). -
TM (neregistrovaný)Tak s touhle vetou bych nesouhlasil (u excelu):
Takovýto CSV soubor pak nelze jednoduchým způsobem načíst např. ani v Excelu nebo Calcu, protože čísla menší než tisíc jsou konvertována na číselný datový typ, ta větší (přesněji řečeno ta s mezerou) zůstávají jako text. Pokud soubor CSV prejmenujete na TXT a date ho otevrit v excelu tak se vam nabidne moznost importu - v ni si nastavite co se ma pouzit jako oddelovac a pak datove typy jednotlivych sloupcu - pak se excel nechova "inteligentne" a neodhaduje jejich datove typy. I kdyz musim uznat ze ten postup je vhodny jen u CSV ktere maji pevny pocet sloupecku - coz v tomto pripade neni uplne splneno -
Zatím ne. Ale kdysi dávno jsem dělal (v Javě) pokusy s ANTLR. Ten se mi zdál dost dobrý. Všiml jsem si, že poslední verze už má taky nějaký výstup do Ruby, ale žádnou osobní zkušenost s tím nemám.
Jinak kód toho parseru, co generuje Ragel, není v Ruby a Javě (na rozdíl od C/C++) zrovna moc efektivní (což mi ale nevadilo). Kdybych to ale chtěl dotáhnout na nějaký obecnější parser podobných CSV-like souborů, tak mi to nepřišlo jako špatná startovní pozice. -
Rejpal (neregistrovaný)Vřele doporučuju aspoň si přečíst v knize Beautiful Code kapitolku Top-Down Operator Precedence: http://javascript.crockford.com/tdop/tdop.html ;-) Je to přinejmenším docela poučné. :-)
-
Milan (neregistrovaný)Ahoj,
tak jsem si zase precetl tu hutnou diskusi a nezbyva mi nez napsat:
Dik za zajimavy a pekny clanek!
Lidi co jen kritizuji, takovejch by bylo.
Sice nedelam v ruby, ale podobne problemy mam na stole dost casto (konecne nekdo prisel s praktickym problemem). Btw. oblibou CS je menit format bez predchoziho informovani. To ostatne delaji i ostatni "ustavy". Takovyto parser je podleme cool svoji obecnosti (to je mimochodem zmineno i v jinych nazorech) a jednoduchosti rychle implementace zmen.
Jo a kdo neklikl na ten odkaz "bizardnimi zpusoby" - vrele doporucuju, je to fakt bizardni kombinace :)
A co se nazvu promennych tyce, proc ne cesky? kdyz je celej clanek cesky.
Dik za clanek, kterej je vecnej, resi problem tykajici se vice uzivatelu, ma spetku srandy, atd ... -
VM (neregistrovaný)Poustet s nazvem vstupniho souboru jako s parametrem:
#!/usr/bin/perl -w my $row; do { $row=<> } while $row !~ /^\s*$/; $row=<>; my @headers=map {$_=~/^"(.+)"$/ ? $1:$_} split ',',$row; while( $row=<> ) { my @data=map {$_=~/^"(.+)"$/ ? $1:$_} split ',',$row; printf "%s\n", join ', ', (map {"'".$headers[$_]."' => '".$data[$_]."'"} (0..@data-2)); } -
Nic ve zlém, jen mi přišlo usměvný, že se spousta diskutujících snaží najít různá řešení jednodušší, kratší nebo taková, aby se vyhnula použití KA. Ale ten článek opravdu nebyl míněn jako soutěž v programování, ani jako snaha o nalezení co nejstručnějšího algoritmu pro daný konkrétní případ.
A v čem se náš přístup liší? Pokud ze sebe vydoluju ještě nějaké zbytky znalostí Perlu (teď za to neručím, s Perlem jsem už pár let nedělal), tak mám pocit, že přeskakujete tu první část souboru a parsujete jen tu druhou. Nicméně hlavní rozdíl vidím v tom, že pokud budu mít se současným řešením výkonnostní problém nebo budu chtít rozšířit třídu parsovaných souborů, tak s Ragelem se mi zdá flexibilnější pro nějaké řešení - ale berte to jako IMHO.
Doufám, že mi odpustíte to rýpnutí do Perlu, ale s Perlem mám vždy trochu pocit, že zdroják je buď zašifrovaný nebo alespoň prohnaný přes nějaký "obfuscator". Ale jistě, kdo s ním víc dělá, většinou nemá problém. -
VM (neregistrovaný)Porad v tom zadne vyhody nevidim - misto par radku to je nekolik stranek, ktere delaji prakticky to same (ano, prvni cast jsem preskocil, ale jeji parsovani by byl jeden radek navic). Navic to reseni v Ruby potrebuje knihovnu, kdezto to perlove si vystaci se zakladnimi jazykovymi konstrukcemi - tim padem odpada potreba knihovnu mit, inicializovat atd.
Vykonnostni problemy by se u toho perloveho moc vyskytovat nemely - Perl je na podobne zpracovani optimalizovany, a dosahuje u podobnych uloh vykonu srovnatelneho s programy psanymi v C. Pokud si dobre pamatuju, tak Pavel Satrapa tohle meril, a zjistil, ze napriklad pri grepovani v textu Perl dokonce prekona specializovany program grep. Jinak ma kod linearni slozitost, jedine neefektivity ktere vidim jsou odstranovani uvozovek pomoci regularniho vyrazu, a to, ze se parsovana data prochazeji dvakrat (stipani podle carek, a odstranovani uvozovek), i kdyz by je teoreticky stacilo projit jednou. Takze pocitam, ze reseni vykonnostnich problemu u zmineneho programu v Ruby bude o priblizovani se k vykonu toho perloveho. No ale proc to nenapsat rovnou optimalne, zvlast kdyz je to tak jeste kratsi...
No a pokud budete chtit rozsirit tridu parsovanych souboru, je to v obou pripadech na predelani programu. Tohle parsuje cokoliv typu <smeti> <prazdny radek> <seznam hlavicek> <csv data>, kdyz z toho budete chtit udelat napriklad parser CSV obsazeneho v XML, tak musite jeste pouzit prislusnou XML knihovnu...
Co se te prehlednosti tyce - dobre, regularni vyrazy byvaji celkem neprehledne, ale ve slozitych konstrukcich na mnoho radek se clovek ztrati taky spolehlive.
No dobre, asi to kazdy bereme jinak. Jen se marne snazim pochopit duvody, proc takovehle reseni muze nekomu pripadat lepsi... -
Rejpal (neregistrovaný)
"Navic to reseni v Ruby potrebuje knihovnu, kdezto to perlove si vystaci se zakladnimi jazykovymi konstrukcemi - tim padem odpada potreba knihovnu mit, inicializovat atd."
To bude nějaký omyl, to řešení žádnou knihovnu nepoužívá - tedy pokud pomineme skutečnost, že se samo do knihovny dá zabalit. Ragel není knihovna, aby nedošlo k mýlce. :-) -
PERL je zvláštní. Vždycky si říkám, jestli se autorovi kódu zasekl shift. Zápis je sice úsporný, ale k čemu to, když je nečitelný? Když jsem psal v PERLu, za měsíc jsem musel horko těžko luštit, co jsem vlastně napsal. Samozřejmě nic proti vkusu jeho uživatelů. Kdybych celý život používal vi a mastil regexpy, možná by i mě PERL přišel intuitivní.
-
VM (neregistrovaný)To ze je zapis usporny je dulezite - nemusite lustit nekolik stranek kodu, staci nekolik radek. Lepe se v tom pak orientuje, i kdyz kazda radka vyzaduje vice pozornosti, a lepe se to i ladi. Ano, regularni vyrazy jsou casto necitelne, ale kdyz to napisete bez nich, tzn. rozepisete do slozitych jazykovych konstrukci, tak je to taky necitelne, a krom toho jeste neefektivni a neprehledne.
Jinak na problemy jako tenhle je Perl jako delany. Pouzite reseni mi prijde jako kanon na vrabce. Takhle jsem psal, kdyz jsem se ucil programovat.
Programovaci jazyk jako Perl mi prijde dost intuitivni - na rozdil od tech ukecanych v nem na jednu myslenku nemusim nasat pul stranky kodu. -
PERL se lépe ladí? No, to bych fakt neřekl.
Dnes je takový trend mít jazyky ukecané. Je to dobré v tom, že se snáze učí, snáze se kód čte, a celé je to jednodušší. Ten prastarý zvyk z počátků oboru, kdy se každému speciálnímu znaku přiřadil nějaký význam, je za námi. Já říkám naštěstí. Uživatelé unixů to možná nesou nelibě, nevím.
Regexpy mají při parsování samozřejmě smysl. Nevýhody jsou ale zjevné. Regexp má po čase problémy přečíst i autor, natož kdokoliv jiný. I triviální konstrukce typu /s/\//\\/g je daleko méně čitelná, než s.ReplaceAll("/","\").
Perl vám může přijít intuitivní, jen pokud jste v něm opravdu zběhlý. Jenže dostatečně zběhnému člověku přijde intuitivní cokoliv, včetně vi. -
VM (neregistrovaný)Opravdu nesouhlasim s tim, ze se ukecanejsi jazyk snaze uci, snaze cte, a ze je to cele jednodussi.
Za tri roky profesionalniho programovani v Jave jsem spise zjistil, ze v ukecanem jazyku se jednoducha vec zapise do nekolika velkych souboru. Pokud k tomu neni perfektni dokumentace, tak se v tom vubec neda vyznat uz jen kvuli rozsahu vysledneho kodu. Nehlede na to, ze pres ukecane jazykove konstrukce neni videt to podstatne. -
Já naposledy vážněji psal v Javě před cca 10 lety (tedy nevážně, ono to tehdy moc vážně nešlo), takže dnešní Javu až tolik neposoudím. Faktem ale je, že je důležité kód správně strukturovat, jinak se snižuje přehlednost.
Vy nevidíte přes ukecaný jazyk podstatné věci, a já nevidím skrz změť !@#$%^&*() znaků, co vlastně kód dělá. Obojí se dá překousnout, ale myslím si, že nečitelný kód musí člověk louskat dlouho a často, než "prohlédne". Můj názor je, že člověk nepostižený historickými jazyky s nimi má větší problém, než opačně. -
S tím si dovolím nesouhlasit. Je samozřejmě na každém, jaký zvolí prostředek a jak s ním naloží. A je samozřejmě možné, že někdo kód v Javě přetříduje a zbytečně překomplikuje. Nicméně pokud správně zvolí názvy identifikátorů, je kód obyčejně docela srozumitelný i bez dokumentace a tu snad všichni píšeme, nebo ne? Pokud někdo pojmenovává proměnné i, j, k, s a třídy MyClass, je to něco jiného.
To podstatné samozřejmě vidět je, protože člověk postupuje od celku k detailu a ty detaily jsou podstatné jenom zřídka. -
Biktop (neregistrovaný)> Ten prastarý zvyk z počátků oboru, kdy se každému speciálnímu znaku přiřadil nějaký význam, je za námi. Já říkám naštěstí. Uživatelé unixů to možná nesou nelibě, nevím.
Ono je dnes třeba rozlišovat programování a programování. Neustále říkám, že dříve vyráběl nábytek jen truhlář. Pak přišla strojní velkovýroba, ale truhlář zůstal. Zůstal tu proto, že to, čím se zabývá on, je přeci jen trochu jiná liga, než ta velkovýroba. A s programováním je to přesně to samé. Naši klienti netvoří tak početnou skupinu, jako u těch druhých, ale vyžadují fajnovou práci a jsou ochotni si za ni náležitě připlatit. Směšovat naše nástroje s těmi určenými pro ty druhé je jako srovnávat počítačem řízené frézy s hoblíkem, cidlinou, rašplí - s tím se každý nenaučí, ale když už se to naučí, tak s tím dokáže to, co ti druzí s těmi svými elektrickými frézami nikdy. -
To by mě zajímalo, v čem spočívá fajnovost té práce. Je to něco jako restaurování starožitností? S tím se dá srovnat třeba psaní v COBOLu. Ne, teď vážně. Na tomhle světě je třeba psát obrovskou spoustu kódu, abychom uspokojili tu explozi poptávky po službách našeho oboru. Je tedy důležité používat takové jazyky, které se snadno učí, a ve kterých se dá rychle a efektivně tvořit. Podobně dokud počítače používala velmi omezená skupina lidí, nebyl problém je ovládat přes command line. Dnes s počítače pracuje i obsluha ve videopůjčovně, a dokonce nemá na pracovišti žádného admina, takže interface musí vypadat úplně jinak. Podobně s těmi jazyky.
Na druhé straně PERLu přiznávám, že když už se ho člověk naučí, je to svým způsobem sympatický jazyk, a v některých věcech celkem silný. Bohužel se dnes méně zabýváme posouváním stringů, a více děláme takové ty tanečky okolo objektů, komponent apod. -
Biktop (neregistrovaný)>Je to něco jako restaurování starožitností? S tím se dá srovnat třeba psaní v COBOLu.
Budete se divit, ale i takové věci. Je tu software, který vznikal poměrně dávno, často běží na hardwaru podobných charakteristik, ale neustále se používá a existuje mnoho důvodů, proč ho zatím používat i nadále. Ale např. takovou atomovou elektrárnu taky neřídí dvoujádrový nabušený procesor, stejně jako raketoplán, jejich řídící software se nepíše v Javě a rozhodně to není z historických důvodů. Příkladů se najde řada.
> Na tomhle světě je třeba psát obrovskou spoustu kódu, abychom uspokojili tu explozi poptávky po službách našeho oboru. Je tedy důležité používat takové jazyky, které se snadno učí, a ve kterých se dá rychle a efektivně tvořit.
O tom jsem mluvil - to je ta "sofwarová velkovýroba".
>nebyl problém je ovládat přes command line. Dnes s počítače pracuje i obsluha ve videopůjčovně, a dokonce nemá na pracovišti žádného admina, takže interface musí vypadat úplně jinak. Podobně s těmi jazyky.
Jenže jsou oblasti, kde se vystačí s tou command line a raději se budoucí obsluha pošle na důkladné proškolení, než aby se generovaly statisíce řádků kódu potenciálně zatíženého chybou (čím víc kódu, tím víc chyb). A vývoj takového softwaru se obvykle nesvěřuje lidem, kteří mají problémy zvládnout tradiční programovací jazyk. Asi byste nešel na operaci oka, kterou provádí laser řízený programem, který napsal člověk, jenž za uplynulý půlrok zvládnul nějaký ten "moderní" ultra jednoduchý jazyk určený k "ultra efektivnímu" psaní kódu, aniž by měl přehled o tom, co se vlastně pod tou slupkou všechno děje.
A to je právě ten rozdíl. Mezi spotřebním softwarem a softwarem, na jehož efektivitě a spolehlivosti záleží životy nebo obrovské sumy peněz.
Proto domnívat se, že zmiňovaným věcem v počítačovém průmyslu odzvonilo, může jen člověk, který o tomto oboru ve skutečnosti nemá přehled. Možná třeba právě taková programátorská rychlokvaška, která se před půlrokem naučila Javu a myslí si o sobě, že se z něj tak stal počítačový expert ;-) -
tukan (neregistrovaný)Musím říct, že s tímhle příspěvkem souhlasím na 1000%, v každém bodě. Jen bych dodal, že rychlokvašky nejsou nutně jen lidi s půlroční zkušeností v Javě. Moje zkušenost je, že u člověka co začal s Javou (neberu Pascal a C ve školách jako programování) a píše v Javě (viz sféra podnikových aplikací a jejich čvičopičí tvůrci) tak půl roku nebo čtyři roky - není v tom rozdíl. Jejich schopnosti začínají a končí u slepování předprogramovaných komponent.
-
Dobře vím, že existují i aplikace v COBOLu. Pár jsme jich migroval do jiného prostředí (typicky .NET). A také vím, že například na space shuttle jsou GPC odvozené od IBM System/360, SW psaný v HAL/S, je tam i veliká spousta PC HW běžího na MS-DOSu atd. Historie je všude kolem nás, proto hovořím o restaurování starožitností. V těchto případech jde zjevně o historické důvody. Údržba je takové věci je dražší, než údržba novějšího kódu, ale na druhé straně levnější, než nahrazení novou technologií.
Vyjma "obecného" IT existují samozřejmě i velmi specializované obory. Například life-critical systémy typu řízení jaderného reaktoru. Kupodivu managed jazyky typu C# mají v této oblasti veliký potenciál, protože umožňují formální verifikaci nejen návrhu, ale i kódu. Ale to se bavíme o trochu jiné třídě SW, než parsování bankovních výpisů :)
Jsou asi oblasti, kde je command line výhodou. Uvědomte si ale, že i dobře proškolená obsluha se uklepne. A kde se začne přemýšlet nad tím, na kolik vyjde školení obsluhy, a na kolik údržba prastarého systému, skončí se často u GUI stavěného podle Fittsova zákona. Podotýkám, že kritické systémy typu řízení letového provozu jsou čistě grafické.
http://en.wikipedia.org/wiki/Fitt's_Law
Systémy typu řízení laseru při operaci oka zpravidla nepíší lidé, kteří mají za sebou jen půl roku školení, nebo mají problémy zvládat programovací jazyk. Přesto existuje hromada případů, kdy software psaný skalními profíky v "tradičních" jazycích selhal. Mnohdy díky stupidním chybám, viz overflow při přetypování u Ariane 5 flight 501 (ztráta údajně DM 1.2G).
Kudivu právě banky, kterými protékají obrovské částky, jedou hromady SW psaného ve všem možném, včetně Javy, .NETu a Visual Basicu.
Spolehlivost SW je věcí více faktorů. Jde o celý řetězec plánování, developmentu, verifikace, QA atd. Kompetence zúčastněných je jistě jedním z klíčových prvků. Ale zdá se mi, že zaměňujete použitý jazyk za kompetenci programátora. -
tukan (neregistrovaný)No nevím jak moc znáte Perl, ale já když dělám cokoli netriviálního (tedy pokud nejde jen o nějaký filtr), tak je všechno objekt. Dalo by se říct, že Perl sám o sobě doporučuje/podporuje objektový přístup. Některé jeho složitější konstrukty/funkce jsou dostupné jedině objektově (viz tied objects). Z jakéhokoli modulu uděláte objekt jedním řádkem.
Po pravdě, Perl je vůbec nejhutnější jazyk co znám (aktivně používám). Tím myslím možnost vyjádřit svůj záměr co nejrychleji a přitom v podstatě přirozeným jazykem. Přijde mi, jako by se lidi podívali na verzi z r.1980 a z toho pohledu jej hodnotili dnes. Víte, že polovina z 10 nejnavštěvovanějších sajt současného Internetu je postavená na Perlu? Na javě jedna a na .NET žádná. Málokterý jazyk je tak univerzální a přitom efektivní a stabilní. Používat Perl jako lepší awk = zahodit 99% jeho možností.
Stejně tak je to i s modulárností toho jazyka. Perl interpret můžete taky jednoduše integrovat do vlastních aplikací v nižším jazyce, atd, atd. Pro GUI programování je mnohem lepší než nějaká Java. Kromě toho, že takové GUI je rychlostí někde jinde než loudavý SWING nebo SWT, odpadají typické Javové problémy s vlákny, je možné cokoli prostě upravit a okamžitě bez rekompilace používat. Naopak ale můžete Perl zkompilovat do nativní binárky a skrýt tak svoji implementaci mnohem lépe než v Javě, kterou si dokáže bez problému dekompilovat kdokoli. Po čistě teoretické jazykové stránce má ve skutečnosti v konstruktech a principech, které podporuje, Perl nad Javou nebo C# převahu.
Nezapomínejme, že jazyk je jen jazyk. Jak v něm vypadají programy, jak jsou rychlé, pomalé nebo špatně napsané - nic z toho není v moci Perlu ani jiného jazyka ovlivnit. Že někteří v Perlu píšou "prasácky"? Proč ne, je to jejich volba. Pokud jazyk umožňuje tak širokou škálu možných přístupů, tak je to jedině dobře. To neznamená, že v něm nemůžete psát jako v Javě. Nemyslím, že restriktivní jazyk je lepší jazyk - naopak. Dává vám totiž menší volnost, což často znamená víc práce pro vás. Kdo je tak moudrý, že si může dovolit hodnotit programátorské potřeby všech a za všech situací? A kdo je tak hloupý, že takovému přístupu může přitakávat?
Když chci mít něco rychle hotové, použiju Perl. V Javě nebo C# by mi to zabralo 10x tolik času. Ale když chci psát modulárně, objektově a tvořit reusable kód - můžu! O tom to je, o volnosti.
Stejná volnost stojí z části za úspěchem Linuxu oproti Windows. V Linuxu můžete jeden problém řešit mnoha způsoby. Ve Windows na to je jedna cesta, tak jak se ji rozhodli vytvořit a prosadit tvůrci systému. Ten druhý přístup nemám rád, svazuje mě. Přestože mi Linux poskytuje větší volnost a třeba i volnost udělat ještě horší řešení než je to ve Windows, tak důležitá je možnost volby. Nakonec, klidně můžu i Linux obsluhovat klikáním jako ty Wokna. Chápete? -
Nejsem velký znalec Perlu, protože mě odpuzuje právě ta nečitelnost. Navíc jeho praktické užití je pro mě prakticky nulové (unixových systémů je kolem mě málo, na Windows máme jiné - a podle mě lepší - prostředí).
Když chci mít něco rychle hotové, používám VBA či VBS (taková obdoba používání bashe a awk na unixech), na většinu ostatního C#. Pokud je to nutné, dovedu psát třeba v ASM, Perlu a dalších, ale z vlastní vůle tak nečiním.
O Javě jsem diskutoval jinde, třeba zde: http://www.root.cz/diskuse/2555/181743/vlakno/#o184303
V krátkosti považuji Javu za pěkný jazyk, ale špatnou platformu. GUI v Javě je pomalé, a vůbec psát GUI aplikaci v Javě je na pováženou. Ovšem raději bych použil Javu, než Perl. Konkrétně Perl/Tk se mi fakt nelíbí. Já jsem zmlsaný těmi věcmi typu IDE, debugger, GUI designer atd. Není to samozřejmě nutnost, ale šetří to čas, tedy pomáhá za stejnou dobu vydělat více peněz (a proto tu práci děláme, že).
S úspěchem Linuxu proti Windows bych nesouhlasil. Linux dnes nahrazuje profi unixy, na desktopu (kde jich nikdy moc nebylo) i na serverech. Ale jako úspěch proti Windows bych to neviděl. Osobně mám rád, když se jednoduché věci dělají jednoduše. A když existuje nápověda, lokalizace, dokumentace, příklady a tutorialy. Linux je fajn na hraní, když člověk nemá co dělat. Já potřebuji pracovat. Natáhnout IDE, napsat kus kódu, a mít po ruce kvalitní dokumentaci. A když už něco píšu, rád slepím hotové komponenty, pokud je to efektivní (nehodlám například psát vlastní OCR nebo reporty). Chci také snadno přehrát video nebo DVD, koupit hru a bez problémů si jí zahrát atd. Počítače jsou dnes jako voda, elektřina nebo mikrovlnka. Musí "prostě fungovat". Jako obor v tom máme co dohánět, a Linux nám v tom moc nepomůže. -
Když chci mít něco rychle hotové, používám VBA či VBS (taková obdoba používání bashe a awk na unixech), na většinu ostatního C#. Pokud je to nutné, dovedu psát třeba v ASM, Perlu a dalších, ale z vlastní vůle tak nečiním
VBA je hodně pěkná technologie - ale není samostatná, je svázána s Microsoft Office - pokud potřebuji dostat data do databáze, tak protlačovat je tam skrz Excel je klasické drbání levou rukou (a bohužel se tak děje dost často). VBS je extrémně prostoduchý a pomalý jazyk - i když zmíněné parsování by se v něm asi zvládlo taky, a hlavně už je opravdu artefakt. Jinak, když v Unixu chcete mít něco rychle hotového, tak právě sáhnete po sedu, awku nebo třeba Pythonu - kdy dokážete s textovými daty poměrně čarovat (pokud víte jak na to). A pokud potřebujete výkon nebo robustnost, tak sáhnete spíše po Yacu. Obě platformy poskytují +/- podobné možnosti, GUI designer, debugger, IDE existují pro Perl, pro Python o Javě nemluvě. Mimochodem pomalost Javy už je naštěstí mýtem - v 6 zapracovali (konečně) a i k mému překvapení aplikace nad Javou 6 jedou srovnatelně s .NETem. Pokud mohu říci svůj názor - řekl bych, že dochází docela k zajímavé konvergenci - pár komerčních balíků komponent existuje jak pro .NET tak pro Javu. Historie o.s. do deseti let skončí. Nikoho moc nebude zajímat co je vespod. Pokud se bude volit mezi o.s. pak na základě politických rozhodnutí a nikoliv na základě technických kritérií, protože ta vzhledem k výkonu hw budou neadekvátní. V blogu Marka Olšavského se můžete dočíst, že k OSS se přiklánějí technicky zdatnější uživatelé, jelikož jim OSS poskytuje větší prostor pro seberealizaci a také nevýhody OSS jsou pro ně minoritní. Ostatní uživatelé budou preferovat uzavřený kód, kdy výhody OSS jsou pro ně nepodstatné (nedokáží je využít) a nevýhody markantní (a takových i mezi vývojáři bude většina). Takže nějaké preference tu budou, nicméně budou subjektivní - nikoliv objektivní. Co se týče přiblížení se IT obci - Linux už své udělal - bez webů a bez internetu by rozhodně počítače nebyly v každé rodině. A to ostatní - mám takový pocit, že nikdo moc neví jak dál - revoluce skončily, teď už se pokračuje evolučně, a přiznám se, že je mi jedno, jestli mám v mobilu Linux nebo Microsoft, pokud mi mobil jede a nezdržuje.
-
VBA není jen věc Office, umí ho i jiná prostředí. VBS je v VBA velmi podobný, a umožňuje použít COM (tedy skriptovat MS Office, když na to přijde). Excel je pro mě podobný nástroj, jako na unixech řekněme vi+awk+perl+sql client.
Jestli tvrdíte, že Java 6 má zajímavý výkon, někdy to zkusím. Přímné překvapení (tj. realita lepší očekávání) vždy potěší.
Že historie OS skončí, to tvrdil Sun, když uváděl Javu. Shodneme se ale na tom, že současný vývoj je spíše evoluční. Revoluci očekávám od systému typu Singularity (tedy zásadní zvýšení spolehlivosti), nebo od zásadní změny pojetí UI. Jistě jste viděl třeba ta dema, kde zavoláte na ústřednu, a virtuální asistentka vás pomocí dialogu mluveným slovem umí přepojit, naplánovat s vámi meeting, posunout naplánovaný meeeting apod.
Zatím jsem neměl v ruce mobil (resp. XDA) s Linuxem, je to pořád velmi exotická věc. Protože jsem pragmatik (jako většina lidí), platforma XDA mě netrápí, pokud můžu nosit Outlook v kapse, existují pro něj důležité aplikace (pocket office včetně Excelu, GPS navigace typu TomTom, slovníky, klient IS apod), a nejlépe je tam i možnost snadného vývoje aplikací. -
polymorpheus (neregistrovaný)jenomze na vsechno neni metoda pomete treba tento prikladek:
s = "some /relative/path" puts s.gsub(/ \//, ' ') # "some relative/path"
tady zadne s.ReplaceAll("/"," ") nepomuze a vlastne ve stejne logice mozna mel postupovat autor clanku - stacilo treba nacist dany soubor do stringu (coz by snad nemel byt problem, tedy podle toho, jak jsou ty soubory velke), pomoci split na prazdnem radku jej rozdelit na dve casti, a tyto dve casti pak jednoduse zpracovat (viz reseni od VM, tusim - ty regexy jsou jednoduche a stejne by vypadaly i v Ruby, vlastne cele reseni by v Ruby bylo dost podobne, i kdyz celkove o dost citelnejsi) vysledkem jsou datove struktury (pole), obsahujici napriklad string " - 1 000 ", ktery se da zpracovat treba takto:" - 1 000 ".gsub(' ', '').to_itakze fakt jednoduche, a o znalost Perlu ani tak nejde - spis jde o to, aspon trichu umet regularni vyrazy, nic vic, nic min -
Miloš (neregistrovaný)Známe názvy sloupců a vsadím se, že každý má předepsaný formát. Rozdělit řetězec podle oddělovače a hodnoty přiřadit sloupcům není problém. Teprve PAK bych hodnotu upravoval,konvertoval a současně KONTROLOVAL, zda vyhovuje předepsané deklaraci sloupce. Vámi popsaná metoda je nejen kanónem na vrabce, ale navíc číselnému sloupci přiřadí řetězec jen proto, že někdo při pořizování udělal chybu! Smutný výsledek po takové námaze!
Pokud jste chtěl pouze upozornit na existenci Ragelu a jeho možnosti, měl jste zvolit úplně jiný přístup.
-
Přiznám se, že moc nerozumím tomu, co se mi snažíte sdělit. Vždyť popisujete přesně tu metodu, kterou jsem použil, protože dostupné knihovny na parsování CSV v Ruby to dělají jinak (převádějí na odhadnutý datový typ rovnou, bez jakéhokoliv kontextu).
A pokud víte, že každý sloupec bankovního výpisu ČS má předepsaný formát, budu Vám vděčný, pokud mne na ty informace nasměrujete. Já jsem nic rozumného nenašel a "variabilitu" formátu poznávám jen podle toho, že mi občas na něčem parser zhavaruje.
Neřekl bych, že Ragel v tomto případě je kanón na vrabce. Zvažte, kolik úprav by bylo potřeba v Ragelu a kolik v ostatních případech např. pro parsování jen trochu obecnějšího případu, kdy se mohou v hodnotách vyskytnout escapované uvozovky nebo kdy hodnoty nemusejí být povinně v uvozovkách. -
Miloš (neregistrovaný)Určitě je předepsáno alespoň to, který sloupec musí být datumem a který číslem. (Nakonec to lze poznat i ze samotných názvů - přesnější formát není ani potřeba). Escapované uvozovky jsou pro rozdělení nepostatné - rozhodující jsou oddělovače. Pouze je potřeba zjistit, zda se tentýž oddělovač nevyskytuje také v uvozovkách jako součást hodnoty a v tom případě ho dočasně nahradit nebo escapovat. (I když bych se tomu divil - znamenalo by to, že byl zvolen zcela chybně. Ani to však není problém).
Na vašem postupu mi vadí právě to, že je bezkontextový. Každá hodnota se přeci pojí s nějakým sloupcem a k tím i s jeho deklaraci typu. Pokud vím, že sloupec musí být číselný, musí být konvertovatelný na číslo i kdyby byl zapsán exponenciálně.(S tím si váš parser poradí?) Podstatné je, že typ konverze se musí řídit deklarací sloupce a nikoliv pouhým obsahem. Vy snad neprovádíte validaci vstupních dat? A pokud jí chcete dělat poději, budete znovu spouštět parser?
-
Nevím, zda bych to nazval, že je to předepsáno. No, ale OK, jakž takž se to dá odhadnout. Přesnější specifikaci formátu bych ale docela uvítal - když už se např. z nějakých záhadných důvodů ignoruje pro zápis data norma ISO8601, nebylo by špatné mít alespoň jistotu, že rok, měsíc a datum jsou pořád ve stejném pořadí.
Co se týká oddělovačů, tak u CSV právě oddělovač se může v hodnotě vyskytovat - v tom případě musí být hodnota v uvozovkách.
Podle mého názoru je tomu právě naopak - můj postup je kontextový. Vždyť v okamžiku, kdy KA přijme hodnotu ji rovnou páruju se jménem sloupce. V tom okamžiku bych mohl udělat i převod na příslušný datový typ (včetně případných oprav chyb ve formátování čísel), validaci, atd. Po načtení celého řádku lze provést zápis do databáze, případně další operace (např. daná transkace se přiřazuje plátci/příjemci). Zdrojový kód pro převod datových typů, validaci, práci s databází apod. v příkladu (na rozdíl od skutečné aplikace) pochopitelně není, protože se primárně netýká popisu KA v Ragelu a tím ani tématu článku.
-
:-)
Regulární výrazy? Dokonce dva? Jde v nich určitě napsat hodně, ale pro tenhle případ je to IMHO kanón na vrabce. Proč používat složitou technologii, když úloha jde snadno převést na vyhledání podřetězce.
Tak třeba v Ruby by to bylo (uvádím jen vnitřek té smyčky, která iteruje po řádcích):
values << line[1..-4].split('","')Pro ty, co nemluví Ruby: z řádku se odstraní první a poslední uvozovky, zbytek se řetězce se rozdělí v místech, kde je podřetězec uvozovky, čárka, uvozovky. To v Perlu nejde?
Omlouvám se za rýpnutí. :-)
-
tukan (neregistrovaný)Jo, to jde, ale první a poslední prvek bude mít na začátku resp. konci nechanou uvozovku, že? :) Takže po pravdě řečeno, to co já bych udělal jedním výrazem/řádkem, vy byste bůhvíjak obíhal ošetřováním výjimek, které na vaše řešení nepasují.
Kanón na vrabce je třeba zmíněný kompilátor gramatik, ale RE jsou na tohle dělané. Jako kanón na vrabce je vidí jen člověk, který to s nimi podle mě (moc) neumí... V Perlu jsou RE integrované přímo do jazyka, takže není potřeba dělat žádné tanečky kolem jako v Ruby (inicializace, kompilace, provedení a rozhrabávání výsledků). Pro mě je vyjádření v RE zcela přirozené a hlavně mnohem přehlednější než několik větvících příkazů a podmínek. Je sranda vidět podobná řešení, když víte, jak elegantně by se to dalo udělat jednou RE. Ale jak říkám, ne každý umí psát RE bez přemýšlení a lovení v příkladech, nedejbože v dokumentaci. Na druhou stranu máte v něčem _obecně_ pravdu - lidé často používají RE tam, kde nejsou zapotřebí. Přesto je to menší prohřešek než vyhýbání se RE jen proto, že s nimi člověk není moc kamarád. Pokud totiž nemluvíme o vnitřní smyčce, kde se projeví každý spolknutý tik, je RE zpravidla mnohem přehlednější než klasický procedurální postup. Je to otázka okolností a osobních preferencí.
Řešení není jen o tom něco polovičatě udělat a zapomenout, ale taky o rozšiřitelnosti, údržbě, modifikovatelnosti a hlavně odolnosti vůči (nepředpokládaným) variacím ve vstupních datech. Co když např. někde budou před/za čárkou mezery nebo jiné whitespace znaky? Nevím jak v Ruby, ale v Perlu je parametr splitu všeobecná RE, takže by to ještě šlo zaintegrovat záměnou "\s*,\s*" místo "," - to už by v Ruby ale tak snadné asi nebylo. Důsledek: i minimální změna ve vstupních datech by vaše řešení odrovnala a muselo by se dost přepsat. S RE to je otázka přidání 6 znaků.
Nadhodil jste se proč dvě RE. To je jednoduché, pokud mluvíme o ŘEŠENÍ a ne jen výkřicích do tmy, myslíme tím kompletní řešení. Jedna RE na rozparsování tabulkového vstupu, druhá na zformátování všech uvedených možností reprezentace integeru. Hash na uložení celé struktury, jeden element o dvourozměrném poli hodnot (první řádek názvy sloupců) pro každou jednu tabulku na vstupu.
Jak prosté, milý Watsone! :) Díky za konstruktivní připomínku k věci, v určité rovině jste měl pravdu.
PS: pokud mám něco obětovat, tak ten cyklus: Perl umožňuje spuštění programu tak, že se jeho určitá část vykonává v cyklu přes zadaný vstup. Identicky, jako by na začátku programu bylo otevření souboru a zbytek napsaný v cyklu, který na začátku načítá řádek po řádku. :) -
tukan (neregistrovaný)Víte co, není to takhle jednoduché. Používáte jednoduché algoritmy, protože většina lidí je nezná? Programujete GUI aplikace v PHP, protože je ho znají i začátečníci? Ne. RE jsou jedním z elementárních programovacích nástrojů. Pokud je většina neumí, jen to vypovídá o kvalitě současných programátorů. Nemůžete věci nepoužívat, protože se najde někdo, kdo by tomu nerozuměl. Nejdůležitější je řešení, dobré a efektivní řešení pomocí odpovídajících nástrojů. V shellu taky filtrujete pomocí grep/sed RE místo propojení osmi grep, cut, nl, tr, awk procesů. Já např. často grepuju místo 'grep -E' pomocí 'perl -pe', protože za to můžu napsat RE bez přemýšlení - s basic RE co má grep musím přemýšlet jak se vyjádřit v slabším jazyce, což je pruda, protože nemůžu psát na plný výkon a zpomaluje to.
Že autor po čase nerozumí ani vlastním RE se říká spíš jako vtipná poznámka na úkor RE. Není to pravda. Stejně jako když se vracíte k zapomenutému úseku normálního kódu, musíte si RE znovu přečíst. Nikdo si nepamatuje z hlavy všechno co kdy napsal. Pokud ani potom _nerozumí_ vlastní RE nebo vlastnímu kódu, je něco v nepořádku. Znamená to totiž, že při psaní použil něco nad vlastní schopnosti, co se pro daný případ narychlo naučil a stejně rychle zapomněl. To se stát může, ale nevypovídá to o kódu ani RE, vypovídá to o něm.
Mezi námi, RE jsou na programátorské poměry dost jednoduchá záležitost. Kdo je neumí, je jen líný se je naučit...
Ten druhý komentář nakonec taky použil v tom splitu RE - byť jen jako demonstraci. Mohl by to udělat jinak, ale na úkor přehlednosti a jednoduchosti. -
RE jsou důležitým nástrojem při parsování textu. Práce unixového admina odjakživa spočívala ve spouštění utilit, filtrování či parsování jejich textových výstupů, a krmení jiných utilit výsledkem toho filtrování či parsování. Na ostatních platformách se pracuje jinak, a parsování textů je okrajovou věcí. Proto se na věc díváme odlišně.
Jako příklad viz Powershell a seznam servisů, které jsou zastavené:
get-Service * | where {$_.Status -eq "Stopped"}
Get-Service vrací objekty, nikoliv text. Where filtruje objekty, nic neparsuje (na konec by šlo připsat | $_.Start, když na to přijde). Obdobně to vypadá v případě použití .NET jazyků, Win32 API apod. Na unixech je to pravda složitější, protože pro servisy (deamony) neexistuje standardní interface. Nicméně kdybyste měl (a na některých unixech asi máte) seznam daemonů, zřejmě byste ho parsoval - viz první odstavec.
Když se budeme bavit o aplikacích, tak ty opět typicky vystačí bez regexpů. Když dojde na stringy, zpravidla potřebujete ověřit délku, zjistit jestli je řetězec prázdný, jestli řetězec něco obsahuje, jestli je čistě numerický, a zbytek jsou spíše výjimky. Viz například fakt, že v DB dotazech regexpy běžně nepoužíváme. Přitom všechny popsané operace zvládnete pomocí pár metod, které jsou čitelné (IsEmpty, EndsWith, StartsWith, IndexOf, Split, Trim apod).
Rozumět vlastnímu kódu v vlastnímu regexpu je rozdíl. U kódu je typicky při troše inteligence, znalosti angličtiny a byť jen základů daného jazyka zjevné, co dělá (a pokud ne, chybí komentář). Regexpy jsou na čtení daleko větší problém.
Ale jak jsem psal už někdy dříve, kdybych celý život administroval unix, ovládal vi a psal v Perlu, zřejmě by mi to celé přišlo nejen normální, ale i velmi praktické. -
Rejpal (neregistrovaný)Vždyť i v tom PowerShellu píšete napůl v Perlu, viz to "$_" ... ;) A '|' a '-eq' jsou mi taky nějak povědomé. ;-) Ono to nakonec vyjde nastejno, každý podobný nástroj bude mít nějaké vlastní ne zcela intuitivní, ale zato zcela praktické zkratky, jinak bychom skriptovali v poměrně ukecané Javě a C#, což neděláme (doufám). :-)
-
tukan (neregistrovaný)Já bych to dál neroztahoval, co jsem chtěl napsat, napsal jsem - myslím, že si v podstatě rozumíme.
Jen pár posledních poznámek - nejsem admin, ale programátor, takže to parsování a RE prostě používám víc než potřebuje průměrný admin. Ten si vystačí s grepem na celá slova, většinou úplně bez RE. Psal jsem to ze svého pohledu.
Ta vaše ukázka PowerShellu je validní Unix shell výraz. :) Propojení pipama, princip fungování - to všechno MS převzal z osvědčeného Unix prostředí a udělal dobře. Pipe a přesměrování fungují už od dob DOSu, v PowerShellu to je jen okořeněné dodatečnými utilitami, které poskytují různé části Perlu, grepu, atd.
Aplikace bez RE - to je otázka JAKÉ aplikace. Průměrná GUI aplikace, pravda, se bez RE může obejít. Ne všechny aplikace jsou GUI, ne všechna data jsou typovaná a vytahovaná z DB. Ne všem stačí parsování _textu_ pomocí zmíněných metod.
Rozumět _vlastnímu_ RE - tady musím upozornit, že v první větě mluvíte o porozumění _samotného_autora_, k čemuž platí to co jsem napsal. Ve druhé větě jste ale odskočil a najednou mluvíte o porozumění někoho _jiného_, kdo má jen programátorské základy. V té větě máte pravdu, ale to nedokazuje nic z první věty. K této části jsem taky napsal své - tedy že nemůžeme používat primitivní programování jen proto, že jsou lidi, kteří by složitějším věcem nerozuměli. K té první větě pořád platí, že vlastní kód a vlastní RE jsou stejná věc - buď používám výrazivo (kód, RE), kterým rozumím nebo ne. Když jim dobře nerozumím, nemůžu čekat, že jim budu zázračně rozumět za rok lépe.
Poslední odstavec - rozhodně. Dobrý programátor/admin zachází se všemi dostupnými prostředky. Časem zjistí co je na co nejlepší a pracuje efektivněji. Ale RE nejsou závislé na žádném OS, je to univerzální nástroj, stejně jako aritmetika, nebo string funkce. -
No já nevím, když jsem ten svǔj kousek kódu pro jistotu vyzkoušel, tak všechny prvky (včetně prvního a posledního) byly OK :-).
Rád bych těm RE a k vašim úvahám o (ne)vhodnosti použití Ragelu v daném případě napsal pár poznámek:
1. Nevím, zda jste si všiml, ale zápis gramatiky Ragelu a RE je opravdu velmi, ale velmi podobný. V RE např. napíšete, že řetězec začíná znakem S nebo T a pak následuje alespoň jedna číslice jako /[ST]\d+/ , v Ragelu je to ('S' | 'T') digit+ (tedy, když budu úplně přesný, RE se dají použít i jako konstrukční element v Ragelu, takže zrovna tenhle jednoduchý by se tam dal napsat minimálně jako /[ST][0-9]+/). Je v tom ale nějaký rozdíl kromě syntaxe? RE mi to ale umožňují popsat jen na úrovní jednotlivých znaků, Ragel kromě toho úplně stejným přístup (nemusím se učit novou syntaxi/sémantiku) umožňuje popsat i abstraktnější úroveň - třeba řádky nebo sekce v souboru. Z toho důvodu je Vaše úvaha, že jsem nikdy neviděl RE, poněkud odvážná. Čímž samozřejmě nechci naznačit, že je umím lépe než Vy.
2. Zmiňujete rozšiřitelnost a údržbu. To byl právě jeden z důvodů mé volby Ragelu v tomto případě (OK, vím, že RE v Perlu mají "extended" režim). Berte v úvahu, že ten článek z pochopitelných důvodů nepopisuje realitu, ale její podmnožinu. Uznávám, že to možná trochu vypadá, že jsem chtěl naparsovat jen ten jeden soubor s pár řádky z příkladu v článku - to byla asi má chyba, že jsem to dostatečně nezdůraznil. Nicméně jsem toho názoru, že se článek týká Ragelu, ne historie projektu a výběru nástrojů. Ve skutečnosti je několik verzí těch výpisů a můj pǔvodní jednoduchý přístup znamenal, že jsem musel udržovat více jednoduchých verzí skriptů (se všemi nevýhodami - jako třeba propagování oprav chyb do několika větví).
Nemám zapotřebí sám sebe hodnotit, zda jsem programátor spravný nebo nesprávný (když jsem nepoužil ty RE :-), ale jsem programátor dostatečně líný, abych nezvolil Ragel bezdůvodně. Když mám parsovat CSV, tak jako první zvolim (kupodivu?) standardní knihovnu pro parsování CSV. Když narazím na problém, hledám jako další v pořadí lepší knihovnu pro parsování CSV. Když mi nevyhovuje a nechce se mi do ní lézt, abych ji opravil nebo rozšířil a mám případně i další důvody, hledám obecnější řešení. Když jsem uvážil všechny možnosti "standardního" formátu CSV (hodnoty mohou a nemusejí být v uvozovkách, uvozovky v hodnotě jsou zdvojené, různý zápis "prázdné" hodnoty mohou obsahovat oddělovač polí nebo (pokud jsou víceřádkové) i znak konce řádku), tak se mi do RE prostě nechtělo. No a když jsem ještě zvážil, že ta aplikace, co je teď v Ruby on Rails, by nejspíš chtěla přepsat do něčeho jiného (RoR je sice fajn, ale na tu aplikaci to prostě není ta nejvhodnější volba), že mám několik mírně odlišných formátů těch výpisů, tak jsem hledal nejjednodušší nástroj, který mi bude vyhovovat. Ragel byl (a stále myslím je) pro daný účel vhodný kompromis. Navíc váš přístup jednoduchého skriptu má jednu nevýhodu: hodnota a řekněme maximálně řádek je popsán gramatikou (v tomto případě RE), ale vyšší úroveň struktury souboru (popis sekce, jak jsou sekce v souboru řazeny apod.) nejsou vyjádřeny explicitně - popisuje je pouze implicitně zdrojový kód příslušného skriptu. -
polymorpheus (neregistrovaný)V Ruby se s RE pracuje uplne stejne pohodlne jako v Perlu, coz je dano tim, ze Ruby, stejne jako spousta jinych jazyku proste perlovske regexy beze zbytku prejima, v pripade Ruby vcetne operatoru =~, takze odpada vytvareni instanci a 'kompilovani', i kdyz i to v Ruby samozrejme take jde prosim opravdu Ruby nepodcenujte (o Ruby se rika, ze je to next generation Perl) - ma v podstate vsechno, co ma Perl a navic IMHO mnohem lepsi objektovy model, coz rozhoduje Osobne si myslim, ze az bude hotove Ruby 2.0, nastane takova mala revoluce, a ti, co budou Ruby uz znat, budou mit velkou vyhodu:)
-
tukan (neregistrovaný)Ta revoluce začala před lety - Perl 6. :) Má i virtuální mašinu jako Java, jde spojovat s .NET jazyky, Javou a jako jazyk je úplně jinde než současnost (C#, Ruby, Python, atp). Dělá na tom tolik lidí tak dlouho, že pro rychlokvašky typu Python a Ruby by to nebyl fair souboj. ;-)
Nepoužívám ho často, chci si počkat, až bude vše ustálené, ale z neosobního hlediska nic v jeho používání nebrání. TO je jazyk nové generace. Ruby 2.0 a revoluce? Že přetáhne lidi od Perlu? I don't think so. Přání otcem myšlenky? :) Python i Ruby jsou spíš kuriozity adoptované začátečníky, resp. Webovou komunitou. Ruby neznám, je to minoritní programovací jazyk a když jsem se na něj díval naposled, nenabízel nic, co by ospravedlňovalo opuštění Perlu (v této kategorii). To už bych spíš uvažoval o Pythonu, ale klasický interpret mi stačí jen jeden a to je Perl. Neznám jiný jazyk s tolika "magickými" možnostmi, které jsou přesně to, co člověk na rychlovky a parsery potřebuje nejvíc. Tied objekty, globy, introspekce, autoloading, XS a celý C interface pro rozšiřování nativním kódem, neomezeně strukturovtelná datová úložiště bez nutnosti cokoli deklarovat, unikátní princip fungování objektů - to co mnozí vidí jako bastl a slabou implementaci je ve skutečnosti mocný nástroj umožňující neuvěřitelné triky, perfektní debugger, ale i obrovská základna hotového kódu (modulů) ze všech oblastí - prostě špička.
Kombinace C/Perl/Java mi dávají ze současných jazyků nejvíc - každý ve své kategorii. Momentálně prožívám postupný přechod od Javy k C#, v multiplat. se mi Mono+.NET osvědčily a C# 2.0 je moc pěkný jazyk. Jak vidíte, novým věcem se nebráním, ale Ruby je v mém seznamu až na úplném konci.
Už si nepamatuju co a jak jsem hodnotil, když jsem Ruby asi 14 dní zvažoval, ale vím, že co jsem viděl, mě odradilo. Když budu mít čas, rád vám přednesu konkrétní důvody... -
tukan (neregistrovaný)Asi jsme si nerozuměli - Perl a .NET jsou pro mě dvě různé kategorie. Javu opouštím ve _prospěch_ .NETu. Perl je v kategorii Pythonu a Ruby. Mám tři kategorie, klasické (nejčastější) programování v C, pak relativně "platform independent" jazyky na business sračky - Java, C# a nakonec interprety pro parsování, tooly a rychlé a jednoduše modifikovatelné GUI aplikace v Gtk - Perl.
O Monu by se dalo psát hooodně dlouho. Asi nemá smysl popisovat jazyk, toho je na netu až až, takže první a nejdůležitější věc je, že funguje teď(tm). :) Situace vypadá dost dobře, co napíšu v Monu prakticky bez problému funguje v .NET. Opačně to je složitější, protože win lidi často používají i v takto nezávislém jazyce nativní věci jako P/Invoke, DLLka, atp. Něco se dá obejít, něco se musí odseknout, něco přepsat. S tím ale moc problémy nemám, protože neportuju, ale dělám vlastní programy. Týká se to spíš C# knihoven. Nejpohodlnější ale je prostě deployovat Mono runtime s aplikací, a to i na win. Přece jen to dává větší volnost a člověk nemusí tolik testovat na rozdíly oproti .NET, které existují. Mono samo o sobě má skvělý runtime, všechny třídy jsou dostupné se zdrojáky, takže člověk může dělat zkratky a místo subclassování prostě upravit drobnost či dvě přímo v jejich kódu a použít to. Mono běží na plno platformách, takže i samo o sobě je dobré. Jen na serverové aplikace to nemám vyzkoušené. Tam bych asi pořád preferoval Javu, ale to není objektivní hodnocení.
Jinak nemyslím, že .NET má nějaká omezení s ohledem na to, co se v něm dá napsat. Microsoft to prosazuje jako hlavní vývojovou platformu a je to ready. Jde s tím dělat i Web, ASP.NET je plnohodnotné ASP. Já s tím nedělám - pro web znám lepší technologie, ale známý si to chválil. :) -
tukan (neregistrovaný)> Spojit "platform independent" a C# do jednej vety aj ked v uvodzovkach chce dost silny zaludok.
Vážně, anebo si pletete C# (jazyk) a .NET (platformu)? :) V C# můžete psát pro dost platforem, vč. Win i Unixů. Mono je na business sračky použitelné stejně jako .NET, mimochodem. -
Isteze ako jazyk ano ale nakolko ani mono ani DotGNU neimplementuju kompletny .NET tak asi nie su pouzitelne rovnako. ECMA standard ohladom .NET nie je kompletny a naviac stale zostala otvorena otazka patentov a podpory. C# je z dlhodobeho hladiska komercne pouzitelny iba na Windows a kto mysli ze nie vystavuje sa roznym rizikam v buducnosti.
-
polymorpheus (neregistrovaný)super prispevek, takhle ma vypadat flame o programovacich jazycich
kdyz jsem naposledy zjistoval, v jakem stavu je Perl6 (http://perlbuzz.com/), videl jsem frustraci z nedostatku (casu) hlavnich vyvojaru. Nevypada to, ze Perl6 bude v nejblizsi dobe hotov, spise si jeste par (mnoho) let pockame. Na druhou stranu, na Perl6 se take velice tesim, ale mam obavu, ze bude prilis slozity i pro nadprumerne vyvojare
Ruby ani Python rozhodne nejsou rychlokvasky, to je skoro urazka! :) Nikdo, kdo zna Ruby, to nemuze rict, to by totiz zaroven urazil vsechny vyznavace Lispu, Smalltaku, ale i Perlu!
Je sice fakt, ze Ruby pomohl zajem webove komunity skrze RoR, ale prave na RoR je videt, jak je Ruby mocny jazyk. Na druhou stranu Ruby opravdu nepomaha nedostatek kvalitni dokumentace (knihy typu C Primer, C++ Primer Plus, apod.) a ne, Programming Ruby neni dobra kniha (je nekompletni). Nikde treba neni poradne vysvetlen objektovy model a moduly, coz je na povazenou (clovek musi do mailing listu) a nepomaha to adopci sirsi komunitou.
Ovsem celkove lze IHMO rici, ze jedine Ruby ma v soucasnosti co nabidnout Java vyvojarum (ti predstavuji hlavni cilovou skupinu pro dynamicke jazyky) a je to predevsim diky jiz zminovanemu objektovemu modelu, ktery je (rovnez) velmi mocny, pritom je Java vyvojarum urcite blizsi nez objektovy model Perlu (i Pythonu). Dokud Perl nebude mit 'klasicke' objekty, dotud bude oproti Ruby v nevyhode
Ostatni vlastnoti Ruby doporucuji Vasi ctene pozornosti (pro info viz treba The Ruby Way, Ruby Coobook, Ruby Quiz)
Na C# 2.0 jsem se take dival, ale poravde receno, nelibil se mi - ty dynamicke prvky z toho jazyka delaji takovou divnou smesku. Kdyz uz dynamicky jazyk, tak se vsim vsudy (viz i moznost v Ruby znovu otevrit a libovolne menit definici trid) - takze Ruby!
Larry Wall ve svem poslednim poslednim projevu kratce zminil i Ruby, a ze pry mu vadi jeho prilisna deklarativnost nebo co, a ze pristup Perlu (vsechno je text) je ten jediny spravny. Popravde nevim, co se Larrymu na Ruby nelibi a proc by mel byt pristup typu vsechno je text ten nejlepsi spravny... Zda se mi ale, ze Larry to s tema sigilama dost prehnal, coz urcite odrazuje znacnou cast mozna kvalitnich vyvojaru, kterym pak zustavaji utajeny jine super ficury (treba prave RE), coz je pro Perl asi skoda - na druhou stranu je to prilezitost pro Python, ale hlavne pro Ruby
atd. atd. -
Tomas (neregistrovaný)Ty jsi me asi trochu nepochopil, to byla ironie. Byla to narazka na stupidni argumenty typy 'tenhle priklad bych dokazal napsat postupem xy 10x efektivneji na 1 radek'. Takze si dej mokry hadr na hlavu a trochu se zamysli nad tim, jestli se nahodou jednoduche priklady nepouzivaji schvalne. Treba aby to ostatni taky pochopili, vis?
A i kdybys nahodou pravdu, tak se to da napsat slusne a ne timhle ego-masturbacnim zpusobem. -
Nesmysl - clanek ukazuje dalsi technologii, a ta se neda ukazovat (ne vsichni na rootu jsou kovani programatori) na slozitem prikladu. Zrovna v tomto prikladu, a tak jak to autor podal ma smysl uvazovat o necem silnejsim nez jsou regulary - ty se take nehodi absolutne na vsechno, a nekdy je pouziti ucinnejsi technologie spolehlivejsi - odladit komplikovanejsi regular je urcite pracnejsi nez odladit jednodussi gramatiku. Prave, ze diky regularum ustupuji do zapomeni technologie jako je treba bizon, yacc a dalsi. Coz je trochu skoda - regulary jsou perfectni na adhoc psani, ale fakt se dost komplikovane udrzuji a rozsiruji, a v tomto ohledu je pouzivani gramatik vyhodnejsi (a zduraznuji i o neco pracnejsi).
-
tukan (neregistrovaný)Jenže on ji ukazuje, _protože_ tím něco parsoval, nešlo mu primárně o "novou technologii". Kdyby uměl RE, tak ho ani nenapadne na proparsování tak jednoduchého výpisu použít kompilátor gramatiky. :)
Všechno má své místo a s tím souhlasím. Yacc použiju, pokud budu chtít udělat parser vlastního typu konfiguráku, použiju ho na vlastní indentační utilitu, ale nepoužiju ho na parsování tabulkového výpisu. To není jen o náročnosti údržby, ale o efektivitě řešení. Udržovat gramatiku může být mnohem složitější, než upravit dobře napsaný RE. Pojďme nezevšeobecňovat diskusi o jeho řešení na všechna řešení, jen proto, že máte pocit, že málo lidí umí s Yacc a Bison...
Je pravda, že udržovat velké RE může být pro někoho frustrující, ale tady mluvíme o dvou triviálních výrazech. Dobře napsaná RE to projede prakticky bez backtrackování. Pro mě je lepší řešení to, co rychleji napíšu, rychleji budu moci přizpůsobit novému formátu a hlavně co bude parsovat rychleji. Kdyby šlo o nějaký kompromis, tak prosím, ale tady - co se mě týče - mluví ve prospěch RE všechno...
Já mu to neberu, ať si parsuje třeba v Pascalu (proč ne, když může v Ruby), ale nebral bych to jako souboj ideologií nebo důvod k dohadům co je na co lepší. Pravda je jako vždy velmi prostá, místo aby si jako správný programátor našel nejlepší nástroje pro dosažení svého cíle a naučil se s nimi (což se mu časem mnohokrát vrátí a je jedinou cestou k lepším schopnostem), šel cestou nejmenšího odporu a násilím napasoval prostředky řešení na to co umí, bez ohledu na kvalitu řešení. :) -
Václav Štěpán (neregistrovaný)Já bych to nedramatizoval - jasně, že ten soubor ze Spořitelny lze na pár řádcích v Perlu upravit a vyhodit do něčeho, co použijete dál (SQL, vstupy pro Ruby, cokoliv). Na druhou stranu pro mne to třeba zajímavý článek je, protože nejsa z FELu, o generátoru typu Ragel jsem posud neslyšel...
-
tukan (neregistrovaný)
Víme, to už jsi tu říkal. Ale ve skutečnosti jsem odpověděl na tvůj přínosný komentář čistě z pohodlnosti. Potom co jsem si přečet článek a pár příspěvků, potřeboval jsem tlačítko "Odpovědět". Tvoje reakce byla negativní a uprostřed obrazovky - použil jsem tě čistě jako ovládací prvek. Po pravdě - ani jsem to nečet, šlo mi jen o kontext a tvoje milé "OMG" na mě vykouklo.
Možná by bylo lepší, kdyby ses vrátil na ta nečeská fóra. Neber si to osobně, ale lidí, co plní diskuse skřeky o ničem je tu až až. Jen pro upřesnění, já - zjevně na rozdíl od tebe - komentuju vždycky k věci. Stačí se podívat co jsi ze sebe dostal ty a o čem jsem se tu s pár schopnými lidmi bavil já. Je úplně jedno, jestli jsi kéroval do autora nebo čtenářů - pořád to je jen trollí kérování.
Faktem zůstává, že autor je tupec a článek uvádí následovně:
Nedávno jsem dostal nelehký úkol: parsovat bankovní výpisy České spořitelny. Formátování vstupních dat je ale velmi nestandardní a často se nedrží ani vlastních pravidel. Hledal jsem proto vhodný parser, který by si s problémem poradil.
Načež se jal líčit, jak to nakonec vyřešil všeobecným parserem gramatik. Vstupní data jsou přitom v jednom z nejjednodušších formátů co existuje. Kdyby se to jmenovalo Úvod do Ragelu bla bla bla, tak je to něco jiného a docela bych to uvítal jako příjemnou změnu, ale i po tom jak je poslední rok dva root.cz na nic mě stále dostává, když tu vyvěsí článek nějakého začátečníka o tom, jak se pral s CSV formátem, který jinak rozparsuje i dítě. Vůbec nešlo o to, že bych to dokázal napsat líp nebo jinak, to by dovedl každý; bylo to prosté povzdechnutí nad kvalitou obsahu v souvislosti s tím, že se publikují články neschopných zelenáčů, kteří píší o něčem co se naučili při psaní článku. Tos nepochopil? Já fakt žasnu! Vážně jsi mě dostal. Nevěřil bych, že někdo může být tak natvrdlý a nepochopit jednu prostou poznámku k perexu.
Nakonec se to v diskusi snažil zahrát do outu, jakože mu šlo hlavně o Ragel, ale vypadá to blbě, protože o pár odstavců výš píše něco jiného. Ty jsi na tom ale ještě hůř, ze 104 komentářů jsou tvoje 3 a všechny se týkají tvé vlastní poznámky a jak jsi ji vlastně myslel. Měl by sis přiznat pravdu: nikoho to nezajímá, takové plky většina lidí přeskakuje. Jsem ale rád, že jsem si teď přečet i ty plky (tvé tři výtvory mezi nimi). Přišel bych o kopec srandy.
-
Tomas (neregistrovaný)Clanek lze ale pochopit i tak, ze vse az do casti Instalace Ragelu je uvod, zbytek pak stať venujici se zakladum Ragelu (svedci o tom napriklad nadpis Začínáme s Ragelem).
Kdyz uz si chces hrat se slovicky, tak z celkovych 3 komentaru byly 2 k me poznamce. Navic 2 svymi komentari k dosud mym 3 popiras svuj vyrok o tom, ze to nikoho nezajima.
Az budes rozdychavat muj dalsi zbytecny komentar, zkus se zamyslet nad tim, jak svymi hodnotnymi a neagresivnimi prispevky motivujes dalsi potencionalni autory k psani clanku a tim zvysovani urovne Roota. -
Pro mne jako neprogramatora, ktery nezna pojem "parser gramatik" je tohle zajimavy clanek i diskuse.
Bohuzel se ctenari typicky hadaji, ktery jazyk nebo nastroj je lepsi. Tukane, kdyz uz hovoris k veci, nemelo by vyznam se na to podivat z pohledu zacatecnika (pokud jsi profesional tak jsi schopen zmenit postoj) a uvest napriklad, ze tady schazi definice rozdilu mezi RE a parsery gramatik, co ze to vlastne je a tak vubec? Jaka je vhodna literatura, pouziti, nejaky ten prikladek z Tve praxe a nakonec ... jasne ... osobni hodnoceni, ze autor to mohl pojmout trosku jinak?
Hergot, vzdyt diskuse na internetu obsahuji hromadu balastu prave proto, ze lide prosazuji sve Ego. Pripada Ti, ze root.cz je na prd? Fajn, tak treba napis nejaky opravdu sofistikovany clanek. Ale upozornuji, ze pro lidi jako jsem ja takovy sofistikovany clanek bude na dve veci. Abych to upresnil, takovy pekny sofistikovany clanek mi bude na nic a potom na prd. Root.cz chapu jako rozcestnik a ne vysoce profesionalni publikaci pro lidi s dlouholetou praxi a vystudovanym matfyz nebo jaderkou.
Takze kdyz vidim uvod do bashe, tak to prolitnu a kdyby tam byla nejaka chyba nebo mne napadl nejaky pekny trik, tak ho vlepim do diskuse namisto toho, abych si ztezoval jaka banda zoufalcu asi tak muze takovy paskvil cist. Vzdyt je to pro totalni zacatecniky, ze?
Z pozice kritika a komentatora bych se snazil nad tema trosku povznest a pomoci lidem, kteri to potrebuji. Misto toho se z komentaru dozvim, jaka ze jsem socka, ze tohle uz davno nevim. -
Mám v OpenOffice Calcu výpisy z účtu celé dva roky zpátky. Jak jste proboha přišel na to, že se nedají inteligentně načíst?
V otevíracím dialogu pro soubory *.cvs si zvolím znakovou sadu, oddělovací znak (v mém případě středník) a oddělovač textu (uvozovky). S takto načtenými daty rovnou pracuji. Sloupce obsahující datum, mají hned po načtení správný formát, ostatní buňky jsou přednastaveny na standardní číselný formát, který si mohu v každém sloupci libovolně změnit. Celý soubor má nyní 13 sloupců, v roce 2006 to bylo 12. Žádné chyby ani výjimky se po celé dva roky nekonaly.
Chápu, že jste chtěl demonstrovat vytvoření parseru pomocí Ragel, ale nešiřte při tom prosím poplašné zprávy.
S pozdravem FB
-
Mám v Postgresu výpisy už od roku 2004 nebo 2005 (musel bych se podívat), s jejich CSV pracuju už od roku 2002. Na to, že se to nedá inteligentně načíst, jsem přišel tak, že jsem to vyzkoušel.
Když chci použít OO Calc, tak v otvíracím dialogu zvolím znakovou sadu, oddělovací znak (v mém případě čárka) a oddělovač textu (uvozovky). S takto načtenými daty rovnou pracovat nemohu (i když datumy jsou OK), protože většinu čísel mám jako text, takže např. to pak sčítá, tak že "2 000 + 3 000 + 2 + 3" = 5 a nikoliv 5005.
Za celých 6 let, co s výpisy alespoň občas pracuju mám 2 hlavní varianty výpisů, z nichž každá, myslím, prodělala drobné změny (ty nepočítám). Starší varianta měla např. (začátkem roku 2005) 10 sloupců, poslední verze novější varianty jich má 21. Názvy sloupců nejsou vždy kompatibilní (např. dříve "Valuta zaúčt.", dnes "Datum splatnosti"). K chybě došlo jednou, kdy ve výpisu označeném jako měsíční chyběla skoro půlka měsíce. Tedy možná to ani nebyla chyba, ale spíš taková zákeřná vlastnost, kterou jsem nečekal. Ale k horkým chvilkám v účetnictví to stačilo. Od té doby zásadně kontroluju, zda v každém výpisu odpovídá zůstatek součtu obratů. -
Je zajímavé, že docházíme stejným postupem k různým výsledkům.
Používám OpenOffice 2.0.4 na Debianu. Co se týče formátu sloupců, ve kterém se Vám načítá *.csv soubor, i ten lze zvolit v otevíracím dialogu. Nad náhledem tabulky se nalézá položka "Typ sloupce". Po označení sloupce v náhledu tabulky mohu vybrat jeho typ - formát. U mne jsou po základní instalaci OO všechny sloupce defaultně nastavené na "standardní" - což je číselný formát. Pokud mám v *.csv souboru čísla jako 3 500, načtou se mi správně tedy 3500.
Netuším, proč se to u vás načítá jako text, ale mohlo by to souviset s nastavením vlastních stylů.
-
Já to zkoušel v českém OO 2.3.1 (a patrně před časem i v nějaké starší verzi - možná 2.2.x) ve Windows a pokud si to dobře pamatuju, i v 2.3.0 nebo 2.3.1 (teď přesně nevím) v OpenSUSE 10.3.
S typem sloupce jsem nehýbal, ani jsem si nevšiml, že tam něco takového je (máte pravdu, že znám Calc jen z rychlíku :-). Tak jsem se tam podíval a je tam všude implicitně nastaveno "Standardní". Nenašel jsem tam ani žádnou volbu, jak bych mohl u konkrétního sloupce dát natvrdo, že je "číslený". BTW, v té novější výpisu je typ sloupce u prvních dvou sloupců asi obtížně použitelný, protože informace v první části výpisu jsou organizovány po řádcích a ne po sloupcích.
Možná to v OO 2.0 chodí správně, to nevím. Akorát mne napadlo, že když to v Excelu chodí stejně jako v OO 2.3, tak možná v nějaké verzi > 2.0 upravili OO tak, aby to bylo více kompatibilní s Excelem.
Ani přesně nevím, co myslíte těmi vlastními styly - používám Calc opravdu jen jako BFU - prostě tak, jak je nainstalovaný (no vlastně jsem do OO doinstalovával driver pro databázi PostgreSQL, ale myslím, že jsem to zkoušel i na čisté instalaci OO). -
Hynek Olchava (neregistrovaný) 88.81.65.---
Vyzkoušejte přímo službu nebo si stáhněte zdrojáky.
http://www.webconsult.cz/novinky/prevod-csv-ceske-sporitelny-do-abo-pro-money-s3.html
