Přejít k navigační liště

Zdroják » Různé » Microsoftí lízátka pro začátečníky: Šance pro boj s PHP nebo krok zpět?

Microsoftí lízátka pro začátečníky: Šance pro boj s PHP nebo krok zpět?

Články Různé

Poslední dobou se doslova roztrhl pytel se snahami Microsoftu přitáhnout ke své vývojové platformě nové, zejména neprofesionální a začínající vývojáře. Je to dobře, nebo špatně? A má Microsoft šanci na úspěch? Nad těmito otázkami se dnes zamýšlí v rubrice Subjektivně Michal Valášek.

Změnu v oblasti webových aplikací, kde je platforma ASP.NET tvrdě válcována PHP, má přinést nový view engine Razor a zjednodušený vývojový nástroj WebMatrix. Visual Studio LightSwitch má zase obnovit slávu „business“ aplikací psaných ve VBA a Accessu.

Před pěti lety jsem v článku Nechejte maličkých přijíti ke mně skuhral nad neschopností Microsoftu přitáhnout k programování začátečníky, zejména ve webové oblasti. Od té doby se změnilo poměrně hodně. Microsoft uvedl Express edice vývojových nástrojů a přesně v souladu s mými věštbami je nechal zadarmo a bez omezení. Také za posledních pět let přibyla pěkná řádka nových technologií, které jsou většinou dostupné zdarma.

Microsoftu se také konečně podařilo kolem své platformy .NET vytvořit skutečnou vývojářskou komunitu. Vyrojila se spousta blogů a dalších projektů, provozovaných nadšenci z lásky k technologii. Přesto ale zejména u začínajících programátorů na webu prohrává. Proč tomu tak je a co s tím chce Microsoft udělat?

Rodina nástrojů pro začínající a neprofesionální vývojáře má zahrnovat:

  • Visual Studio Express Editions – speciální edice Visual Studia, dostupné zdarma (je jich víc, separátně pro VB.NET, C#, C++, Windows Phone a pro web). Tady se nejedná o žádnou novinku, Express edice jsou k dispozici již od verze 2005.
  • Microsoft WebMatrix – extrémně zjednodušený nástroj pro tvorbu webů, který je momentálně v beta verzi. Bude výrazně jednodušší, než Visual Web Developer Express a bude k dispozici zdarma. Historická poznámka: Microsoft již v minulosti měl produkt jménem WebMatrix, byl to první pokus o volně dostupný editor pro ASP.NET 1.x. Nikdy se nerozšířil, protože ze strachu o prodeje Visual Studia do něj Microsoft neimplementoval mnoho použitelných funkcí.
  • Visual Studio LightSwitch – tajemná edice Visual Studia, o níž jsou k dispozici pouze kusé informace. Má sloužit k vývoji „business data-driven aplikací“, z čehož (a dalších náznaků) lze soudit, že má jít o jakéhosi ideového nástupce Microsoft Accessu a Visual Basicu for Applications. Na rozdíl od Express edic a WebMatrixu nemá být zadarmo.

Spolu s uvedením beta verze WebMatrixu také Microsoft představil nový view engine pro ASP.NET, nazvaný „Razor“. Po ASP.NET Web Forms a ASP.NET MVC se jedná již o třetí způsob, jak psát v ASP.NET webové aplikace.

Reakce většiny mně známých ASP.NET programátorů na Razor a WebMatrix (a přiznám se, že i první instinktivní reakce moje) by se dala shrnout známou zkratkou „OMGWTF“.  A reakce Microsoftu by se dala shrnout jako „vy na to nekoukejte, to není nic pro vás“. Po hlubším zamyšlení pokládám obě jmenované reakce za nesprávné.

Express Editions vs. WebMatrix

Nejčastěji kladenou otázkou při diskusi o Express editions vývojových nástrojů je: jaká jsou omezení? Největší jejich slabinou a zároveň sílou je, že správná odpověď je „žádná“. Vyšší edice Visual Studia vám nabídnou lepší komfort při práci, podporují pluginy, týmovou spolupráci a podobně, ale programování v Express a vyšších edicích se nijak neliší. Jakoukoliv aplikaci napíšete zcela stejným způsobem v libovolné edici. Express vám vývoj nijak nezkomplikuje, ale ani neusnadní.

Je to tak trochu jako s auty a řidičákem: na miniaturního Smarta potřebujete stejný řidičák jako na terénní BMW. Musíte znát stejné věci a projít stejnými testy.

WebMatrix má výrazně menší možnosti, ale zároveň též neporovnatelně jednodušší ovládání. Má pár mega a nainstalujete ho za pět minut. Jeho zásadním účelem není napsat aplikaci od základu (i když i to je možné), ale spíše stáhnout již existující aplikaci, upravit ji a nasadit. To je typický úkol neprofesionálního vývojáře: ne napsat něco nového od základu, ale stáhnout nějakou existující free aplikaci, upravit ji k obrazu svému a nasadit ji.

Vývojáře zvyklé na „velké“ vývojové nástroje WebMatrix rozhodně neoslní. Má zcela jinou logiku ovládání a daleko méně možností. Je to srovnání podobné, jako srovnávat Photoshop s jednoúčelovými prográmky na úpravu fotografií: jakmile se jednou naučíte používat Photoshop, k jednoduššímu programu se nebudete chtít vracet. Ale velká část uživatelů neupraví jedinou fotku, pokud k tomu budu jako jediný nástroj mít Photoshop.

WebMatrix je také hodně optimalizovaný pro Razor view engine, i když by měl umožnit použití obou starších technik. Ostatně, Razor je podle mého názoru ještě důležitější než editor

Tři cesty k ASP.NET

Ač se o tom obecně mnoho neví, ASP.NET nabízí tři základní způsoby, jak vyvíjet webové aplikace. Mají být v zásadě rovnocenné, a to jak co do schopností, tak co do podpory v budoucnu. Časté obavy, že např. Web Forms budou do budoucna upozaděny a bude se rozvíjet jenom MVC (nebo naopak) jsou tedy neopodstatněné.

ASP.NET Web Forms

Web Forms představují služebně nejstarší způsob, jak psát webové aplikace v ASP.NET. Kromě toho, že je nejstarší, je také nejrozšířenější. Proto většinou když lidé mluví o ASP.NET (zejména o jeho výhodách a nevýhodách), mluví ve skutečnosti o Web Forms.

Základní logikou Web Forms je oddělení vzhledu (HTML markupu) od backendového kódu. Toho se dosahuje především používáním serverových ovládacích prvků (server controls), z nichž je stránka složena a které ve výsledku generují HTML.

Tento způsob vývoje je velmi rychlý a umožňuje velkou opakovanou použitelnost jednou napsaného kódu. Kombinací ovládacích prvků, které jsou součástí .NET Frameworku samotného, od třetích stran a vlastních lze obvyklé aplikace vyvíjet snadno. Vlastní stránka (web form) pak slouží v podstatě jenom jako kontejner jednotlivých komponent a má minimální funkčnost.

Typicky uváděnými nevýhodami ASP.NET Web Forms je ztráta kontroly nad generovaným HTML kódem a nárůst velikosti stránek kvůli ViewState, do kterého se serializují stavová data.

Web Forms jsou velmi komplexní systém, který zůstává většinou vývojářů bohužel nepochopen, a výše uvedené nevýhody oni nejsou schopni odstranit – je to sice jednoduché, ale vyžaduje to jistou míru porozumění a pochopení používané technologie. Programátor nemá nad nižšími úrovněmi, jako je přímá práce s HTTP požadavkem a odpovědí či generování HTML kódu, bezprostřední kontrolu.

Logika Web Forms vznikla před více než deseti lety a měla usnadnit přechod k webovému vývoji newebovým programátorům, kteří do té doby vyvíjeli „tlusté klienty“. To může nicméně představovat problém pro začátečníky, kteří nikdy takové aplikace nepsali, proto mají Web Forms nepříznivou křivku naučení.

Začátečníci jsou obvykle schopni ve Web Forms aplikaci nějak zbastlit dohromady vizuálním návrhem, ale taková aplikace má obvykle mnohé neduhy, které jsou potom vytýkány jako chyba technologie.

ASP.NET MVC

V roce 2007 Microsoft přišel s druhým způsobem, jak psát ASP.NET aplikace, totiž s ASP.NET MVC. Zde je implementován architektonický vzor „model-view-controller“, populární i v jiných frameworcích, z nichž asi nejznámější je Ruby on Rails.

Oproti server controls má v tomto případě programátor přímou (nikoliv větší) kontrolu nad generovaným HTML kódem. Další výhody vyplývají z použití MVC patternu, zejména tedy že je možno jednotlivé „vrstvy“ aplikace vyvíjet a testovat nezávisle na sobě. ASP.NET MVC umí pro generování výsledného HTML používat různé šablonovací systémy (view engines). Výchozím view engine jsou ořezané Web Forms, ale existuje jich celá řada.

Příchod MVC sice potěšil řadu technických nadšenců a dočkal se v ASP.NET kruzích jistého rozšíření, ale pro nováčky je minimálně stejně nepochopitelný, jako Web Forms. Pro člověka, který má jenom matné tušení, co je cyklus a co podmínka, je sama idea MVC patternu principiálně nepochopitelná.

ASP.NET Razor

Razor je novinka, kterou Microsoft představil veřejnosti začátkem července. Striktně technicky vzato se nejedná o „konkurenci“ předchozích dvou přístupů. Razor je principiálně view engine, který může být použit v kombinaci s MVC nebo s Web Forms.

Jeho síla nicméně spočívá v tom, že ho lze pro jednodušší situace použít samostatně, a lze s tím začít velmi rychle, bez jakýchkoliv předchozích znalostí. Stačí vzít HTML soubor, změnit jeho příponu na .cshtml a napsat zavináč. Stejně jako stačí soubor přejmenovat na .php a napsat <?. A to je vlastnost, ve které konečně Microsoftu svítá šance oslovit začátečníky.

Profesionálové se při představě bastlení špagetového kódu mezi HTML – pro což je právě Razor ideální – znechuceně šklebí (přinejlepším), ale přiznejme si, že velká část aplikací taková prostě je a že také většina z nás takhle začínala. Frameworky, návrhové vzory a abstrakce jsou úžasná věc, ale programátor k nim musí dojít, představa, že na nich bude začínat, je nereálná.

Ačkoliv tedy z Razoru slintají blahem i někteří zkušení programátoři, kteří ho chtějí používat jako view engine pro MVC, skutečná síla, a troufám si říct, že i hlavní důvod jeho vzniku, je právě v možnosti samostatného použití pro jednoduchý vývoj aplikací začátečníky.

Tomu ostatně napovídá i dosavadní dokumentace. Informace na stránce „WebMatrix Fundamentals“ (http://www.as­p.net/webmatrix/fun­damentals) jsou patrně nejlepším úvodem do programování pro dosud nepolíbené, který jsem zatím viděl.

Razor jako „programovací jazyk“ (píšu v uvozovkách, protože ve skutečnosti je za tím C# nebo VB.NET), WebMatrix jako vývojové prostředí a SQL Server Compact Edition 4.0 jako databáze tvoří dohromady celkem pěknou platformu pro jednoduché aplikace. Je téměř jisté, že stejně jako původní PHP a původní Active Server Pages tahle jednoduchost a nestrukturovanost programování povede k tvorbě dost hrozných aplikací a aplikací příliš velkých, které by si nějaký ten framework zasloužily, ale postupně se vyvinuly z těch malých a jednoduchých.

To byl ostatně osud původních Active Server Pages (ASP): VBScript v nich měl sloužit jenom pro jednoduché operace, pro pospojování COM/COM+ komponent psaných ve „velkých“ programovacích jazycích jako C++. Trochu se to zvrhlo, ve VBScriptu, který na to byl zoufale nepřipraven, se psaly celé velké aplikace, a to vedlo ke vzniku ASP.NET.

Pokud se Razor uchytí, čeká ho patrně podobný osud. Oproti ASP má výhodu existence hotového frameworku, na který lze přejít, když to programátor bude chtít. Oproti PHP má výhodu, že .NET Framework není prostředí jenom pro web, ale je použitelný pro web, desktop, cloud, kapesní zařízení, databázi, jednočipové počítače, XBox… V tomto směru jedinou technologií, která se mu může alespoň přibližně rovnat, je Java.

Velkým potenciálním problémem jsou u začátečnických aplikací bezpečnostní rizika – SQL injection a Script injection. Razor dělá, co může, aby problémy tohoto typu odstranil: zjednodušuje validaci vstupů (a i v dokumentaci o ní mluví na stejném místě jako u jejich samotného načítání, nedává ji zvlášť) a výchozí jednoduché metody pro práci s databází automaticky předpokládají používání parametrizovaných dotazů.

SQL Server Compact Edition 4.0 a IIS Express

Zjednodušení vývoje pro začínající programátory – a tentokrát nejenom pro ně – přinesou i dvě další novinky, které jsou nyní součástí WebMatrixu, ale v budoucnu budou k dispozici i samostatně.

IIS Express je zjednodušená verze Internet Information Services od Microsoftu, vhodná pro vývoj a testování. Běží v uživatelském režimu, na rozdíl od velkého IIS nepotřebujete administrátorská práva ani obsáhlou konfiguraci. Je ekvivalentem ASP.NET Development web serveru, který je součástí Visual Studia, ale podporuje všechna rozšíření „velkého“ IIS 7.0.

SQL Server Compact Edition je nejmenší edice Microsoft SQL Serveru. Původní název a dosavadní zkratka „SQL Server CE“ odkazuje na to, že původně tato edice vznikla pro potřeby mobilních zařízení, ale nějakou dobu je k dispozici i pro „velké“ počítače. Na rozdíl od vyšších edic Microsoft SQL Serveru (včetně Express edice, která je k dispozici zdarma) nebo třeba populárního MySQL se jedná o embedded databázi, kterou není nutné instalovat a která neběží jako samostatná služba. V tomto ohledu je porovnatelná třeba se SQLite.

Dosavadní verze jsou principiálně jednouživatelské, a tudíž jsou nepoužitelné pro účely webových aplikací. Nová verze 4.0 tento problém řeší a bude se tedy pro účely menších aplikací jednat o velmi použitelnou alternativu k „velkým“ databázovým systémům. Atraktivní je mimo jiné, že lze tuto DB použít bez nutné spolupráce hostera, stačí nahrát do /bin adresáře aplikace příslušné assemblies  a je vystaráno.

Oproti jiným embedded databázím má SQL CE výhodu především ve snadném přechodu na vyšší edice SQL Serveru, pokud si to objem dat nebo rozsah aplikace v budoucnu vyžádá. SQL CE také je a bude podporován ve vývojových nástrojích Microsoftu a v technologiích pro přístup k datům – pokud používáte LINQ-to-SQL nebo Entity Framework, lze je snadno použít i pro přístup k této embedded databázi. Entity Framework vám dokonce umožní přecházet mezi „velkým“ a „malým“ SQL Serverem bez nutnosti měnit kód aplikace samé.

Obojí samozřejmě pomůže začátečníkům, kteří budou mít k dispozici webový a databázový server, aniž by ho museli instalovat a konfigurovat (a navíc obojí budou mít jako součást WebMatrixu). Služby IIS Express a SQL Compact nicméně ocení i zkušenější programátoři, kterým usnadní vývoj (IIS Express) a zjednoduší nasazení aplikací (SQL CE).

Visual Studio LightSwitch

Poslední novinka, tedy Visual Studio LightSwitch, poněkud vybočuje z řady zmiňovaných technologií, i když s nimi souvisí. Pro jistotu podotýkám, že o tomto produktu je zatím jenom velmi málo informací a ještě méně z nich je určeno běžným smrtelníkům, takže následující věštby se nemusejí splnit. (Článek vznikl před uvolněním betaverze – pozn.red.)

Zatímco předchozí novinky jsou a budou k dispozici zdarma a předpokládá se jejich použití především začátečníky a koníčkáři, LightSwitch je určen pro business sféru a bude za peníze. Ideově se dle mého soudu má jednat o nástupce Microsoft Accessu a Visual Basicu for Applications, tedy „programování pro neprogramátory“. Patří ke koloritu značného množství menších a středních firem, že „business critical“ aplikace je nesourodý konglomerát MDB souborů a maker pro Microsoft Office. Takové věci často vytvořili neprogramátoři, „správci sítě“ a obecně lidé znalí spíše vnitřních procesů firmy, než jemných umění vývojářských. Podle toho samozřejmě tyto aplikace vypadají a mnohdy drží pohromadě spíše nekonečnou slitovností boží.

Nicméně i takovéhle aplikace mají smysl a své místo, protože řada „odborných“ věcí je, zejména v prostředí menších a středních firem, nesdělitelná. V několika posledních verzích Office Microsoft vývojářské záležitosti a Access hodně upozadil, snažil se programátory přesvědčit, aby i pro vývoj Office aplikací používali .NET a Visual Studio.

LightSwitch, podle mého názoru, má umožnit jednoduchý a rychlý, převážně vizuální návrh data-driven aplikací. Stejně jako v případě Razoru a WebMatrixu bude mít LightSwitch výhodu existence .NET Frameworku a možnost relativně snadného přechodu na „pořádné“ vývojové nástroje.

Závěr

Základní nevýhodou stávajících nástrojů pro .NET Framework je, že v nich lze, pokud to zjednodušíme, programovat buď dobře, nebo vůbec. Tedy: ne že by se v nich nedalo prasit, ale dá to práci. Což bohužel pro většinu lidí znamená „vůbec“, a to i pro většinu těch, co mají na vizitce napsáno „programátor“.

Pokud se Microsoftu podaří rozšířit nové nástroje mezi lid, jistě vzroste množství špatně napsaných .NET aplikací, jejichž autoři nyní realizují svou kreativitu v PHP na úrovni verze 3. Nicméně i tyhle aplikace mají své místo a provázanost s „velkým“ .NET Frameworkem dává jejich autorům snadnou šanci vyrůst.

Komentáře

Subscribe
Upozornit na
guest
48 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Aleš Roubíček

Koukám Michale, že máte se Štěpánem stejný problém. Označujete technologii ASP.NET WebPages za Razor. To je velice nešťastné, protože Razor je pouze šablonovací systém použitelný v jakémkoli jiném frameworku, než je ASP.NET WebPages (bude součástí ASP.NET MVC, přejde na něj i Castle MonoRail, či FubuMVC).
Prosím, přestantě šířit tento omyl. Pokud je to možné, prosím Zdroják o opravu.

Aleš Roubíček

Tak sem článek dočetl až do konce a obávám se, zmatení pojmů Razor vs. WebPages je tak dokonalé, že to snadno opravit nepůjde.

Michal Augustýn

Moc moc pěkný článek, jen škoda toho zkonění pojmů :(

Altair

To co Microsoft teď propaguje a čím se snaží oslovit začínající programátory, je právě kombinace ASP.NET Web Pages a Razoru – a o tom je ten článek. Nepřišlo mi v daném kontextu nezbytné rozvíjet víceméně akademickou debatu o tom, kde přesně je hranice mezi jednotlivými technologiemi a jak se dají vzájemně kombinovat.

Borek Bernard

Akademickou debatu skutečně netřeba, ale toto:
>>> Spolu s uvedením beta verze WebMatrixu také Microsoft představil nový view engine pro ASP.NET, nazvaný „Razor“. Po ASP.NET Web Forms a ASP.NET MVC se jedná již o třetí způsob, jak psát v ASP.NET webové aplikace.
je po faktické stránce prostě špatně.
Jinak se mi ale taky článek celkově líbil, je tam řada dobrých komentářů. Díky za jeho napsání!

Aleš Roubíček

V daném kontextu je právě code name „Razor“ zcela bezvýznamný. Není to žádný nový způsob vývoje. Je to jen šablonovací jazyk. ASP.NET Web Pages je mnohem víc než to. Je to hlavně spousta statických helperů, které nahrazují komponenty známé z Web Forms. Pokud chci třeba box s twitter feedem napíšu @Twitter.Feed("zdrojak") a je tam.
Jeho součástí je taky nový data access framework (aka Microsoft.Data), který zjednodušuje práci s databází a využívá k tomu nové dynamické vlastnosti jazyka. To je důležité. Zmizel lifecycle, zmizela page behind/beside, jde opravdu o pouhopouhé stránky, tak jak se psaly v dobách ASP/PHP.

Tomáš Herceg

„Časté obavy, že např. Web Forms budou do budoucna upozaděny a bude se rozvíjet jenom MVC (nebo naopak) jsou tedy neopodstatněné.“
Kéž bych měl tvůj optimismus.

pepavondepo

V .net, že se nedá snadno napsat špatný kód? No jéje…

dc

Myslim ze hlavny problem prechodu phpckarov na asp.net je v tom ze asp.net ma blizsie k jave ako k php. Php nieje express verzia velkeho frameworku/plat­formy. Je to proste jazyk/interpret so vstekymi svojimi vyhodami aj nevyhodami. Je maly,lahko pouzitelny a dostupny.
Co mne osobne vadi, ked robim v VS a pod .netom/c# je stale narastanie narokov.VS 2010 je strasne nenazrane, uz aj 2008 sa chova pomaly ako eclipse a .net 4 to je niekedy peklo. Ano da sa to obhajit ze staci vykonnejsi HW ale aj to je rozdiel medzi nastrojmi pre PHP (aj ked tie su o dost primitivnejsie) a prave k .Netu/ASP atd. Ved uz pomali NetBeans ktore su napisane v Jave a pre javu su sviznejsie ako VS pre .net.

blizzboz

Mne fachčí Visual Studio 2010 aj na starom dvojadrovom notebooku s 3GB ram úplne svižne. Čo sa týka PHP tak jediné použiteľné IDE pre PHP je NetBeans (skúšal som aj Zend Studio a dosť je zabugované) a to má vyššie hardwarové nároky ako Visual Studio.
Ja vidím hlavnú nevýhodu v PHP že to neni plnohodnotný objektový jazyk. OOP bolo k PHPčku len dorobené a je to tam aj vidieť. Ďalšia vec ktorá mi na PHP vadí je rýchlosť (teda lepšie povedané pomalosť) a veľmi slabá typová kontrola.

Miroslav Holec

S tou „pomalostí“ bych u menších aplikací nesouhlasil.

blizzboz

kompilované jazyky musia byť vždy zákonite rýchlejšie ako interpretované: http://naspinski.net/image.axd?picture=php_v_asp1.png

Jiří Knesl

Co konkrétně z oblasti OOP v PHP postrádáte? Já si myslím, že PHP má naprosto dostatečně zpracování objektů – nebo Vás napadá JEDINÁ vlastnost OOP, která není obsažena v PHP? Jediný návrhový vzor, který nejde implementovat?
Samozřejmě mluvím o syntaxi jazyka, ne knihovny – to by bylo jak kritizovat C++, že není správně objektové, protože v něm fungují i Cčkové funkce. :)
Co se typové kontroly týká, máte samozřejmě možnost v PHP používat type hinting tak, jak jste zvyklý z jiných jazyků. Nemít tu povinnost je ale výhoda (zjednodušuje se např. konstrukce mock objektů, které nemusí implementovat celé rozhraní, ale jen potřebné metody pro test).
Stejně tak implicitní přetypování je pro toho, kdo mu rozumí, výhodou a cestou pro zlepšení čitelnosti kódu:
Ostatně je čitelnější:
$mailCount = sizeof($mails); echo „You have: $mailCount mails“
než:
$mailCount = (string)sizeof($ma­ils); echo „You have: $mailCount mails“

jiravanet

Nevím jak kdo to zařadí do oblasti OOP, ale podle toho co jsem v sobotu viděl, tak scházela podpora pro abstraktní třídu a v ní vytvořenou property/metodu. Díky tomu se začala vymýšlet konvence a různé háčky jak ji využít. Ale PHP neznám tak důkladně, abych řekl, že tam tato podpora schází, jen jí možná přítomní na Poslední sobotě neznali.

Jiří Knesl

PHP umí abstraktní třídy s implementovanými atributy i metodami. Stejně tak umí i abstraktní metody v normálních třídách.
Samozřejmě toto jsou věci, bez kterých se OOP obejde. Self se obejde bez tříd. @optional direktivu (jako je v Obj-C 2.0) většina OOP jazyků nemá. Totéž platí o mixinech. Ruby zas nemá interfejsy (a Python je má externě, ale je to řešení jak z prdele). Mnoho OOP jazyků má primitivní neobjektové typy a řadu funkcí (ne metod, opravdu funkcí přímo ve sdíleném namespace), taky to nebrání objektovosti jazyka (Obj-C, PHP).
Mrzí mě neexistence tříd String a Array, nemožnost mixinů, neuspokojivý zápis (nutnost psát this, formát → místo formátu ze smalltalku, selfu, obj-c) ale nic z toho mě nenutí k neobjekovým kompromisům, jen je to větší práce.

Aleš Roubíček

Ta ukázka čitelnosti je IMO zcela zcestná. Podpora pro string literály je zcela stejně použitelná i v silně typových jazycích. V .net má každý objekt metodu ToString, která se v takovém případě zavolá automaticky.

Jiří Knesl

Aleši, nejsem si jist, zda to tak dělají všechny jazyky. Nicméně řešení v .NETu je rozhodně argumentem PRO slabé typování, ne PROTI. Sám, když se podívám na statické a dynamické jazyky, tak vývoj za poslední roky ukazuje, že se statické jazyky přibližují a vykrádají z dynamických, ne naopak.

Borek Bernard

Nemluvil jsi před chvílí o type hintingu v PHP? :)
Pronášíš věci moc absolutně, svět není černobílý.

Jiří Knesl

No jo no, type hinting, taky má PHP bytecode cache jako obdobu kompilace… :) Samozřejmě i dynamické jazyky si vybírají dobré věci ze statických. Ale bude to asi tak 1:10.
Jako ekonom i jako vývojář v PHP vidím, že problém motivace lidí z PHP komunity (nebo nováčků) k nečemu jinému než PHP leží úplně jinde, než v tom, že „php nemá objekty jako XYZ“, že „my jim nabídneme fancy editor ve WPF, protože nováček se cokoliv složitějšího než PSPad bojí“ nebo že „to má novou šablonovací vrstvu“.
Bojím se, že tohle skončí ve flamewaru, protože problém je tak složitý, že to nejde řešit v 10 větách po internetu plných zkratek, sloganů a ukázek „z okrajů intervalu“.

Aleš Roubíček

Jasně, viz. třeba PHP ;)
Jazyky v mnoha rysech konvergují. Každému vyhovuje něco jiného. Osobně jsem rád že můžu dělat rychlou kontrolu syntaktické správnosti kompilací, logické správnosti testováním a můžu mít i rychlou statickou analýzu. Ale hlavně mám typovou bezpečnost a ta u dynamicky typovaných jazyků nejde z principu nikdy zaručit.
Slabá typovost je pouze dobrá pro slabé mozky. ;)

Jiří Knesl

Už tu mícháme slabé a silné typování, dynamické a statické typování.
Já v PHP mám proměnné staticky typované – ano, dělám to ručně sám od sebe místo nutnosti v jazyku – když mám v promenné string, nepřepíšu ji nikdy intem. Mám-li tam model implementující rozhraní XYZ (a čekám-li, že budu používat přesně to rozhraní), ani na 1 řádku si tam nedám objekt, který toto rozhraní nedodržuje.
Další věc je slabé typování – využívám toho že vím, jaký typ proměnná má (byl ji určet při deklaraci a při běhu se nezmění) a že se umí implicitně přetypovat.

Aleš Roubíček

Jenže dynamické typování je něco jiného než, že do jedné proměnné cpeš několik typů, to můžu i ve staticky typovaném jazyce pomocí boxingu. Dynamický typ vzniká za běhu a lze měnit/přidávat/o­debírat jeho vlastnosti a metody.

Aleš Roubíček

Ale to už jsme silně mimo téma…

Eronlines

A co takhle urychlení pomocí cache kompilátoru? Implicitní konverze jsou podle mě naopak veliká výhoda…

Daniel Steigerwald

Podepisuji se pod to co píše Aleš. Žádný ASP.NET Razor neexistuje a stavět ho na roveň Forms nebo MVC je dadaismus. Forms i MVC jsou webové frameworky, tedy něco co přímá http requesty, něco s nimi dělá, a výstup pak vrací, pomocí view engine uživateli. Razor je právě ten view engine, a není zdaleka jediný. Máme http://sparkviewengine.com/, http://code.google.com/p/nhaml/, brail, nvelocity..
Razor je nový MS oficiální view engine pro MVC. Používám jej a funguje báječně. Malé srovnání s předchozím defaultním view engine: http://pastie.org/1103124
Osobně jsem z této MS edice (chci programovat, ale nechci se toho moc učit) trochu rozpačitý. Jestli někdo chce programovat jenom trochu, tak ať raději neprogramuje vůbec, a někoho si na to najme. Bojím se, že to dopadne takto http://bit.ly/aNy71z
Jinak článek není špatný, až na tu zatrolenou terminologii.

Michal Augustýn

Pokusím se ještě svými slovy uvést skutečnosti na pravou míru…

Webové frameworky (přímo od Microsoftu) postavené nad ASP.NET jsou (jak Altair téměř správně napsal) WebForms, MVC a WebPages.

Úplně stranou nějakého webového vývoje je univerzální templatovací engine s názvem Razor. Razor je pak využíván v ASP.NET WebPages a také jako view-engine pro ASP.NET MVC.

Borek Bernard

Tak, konečně to tady zaznělo úplně a srozumitelně. Výborný popis!

Altair

Máš naprostou pravdu. Nicméně já mluvil o způsobech vývoje, a v tomto kontextu Web Pages a Razor splývají. Právě kombinace web pages a Razoru je IMHO to, pro co platí názory v článku vyjádřené.

keff

Myslím, že každý programátor se stal programátorem tak, že zkusil trochu programovat, neznám člověka jehož hello world by byla MVC aplikace – ale to už padlo v článku…

stej

Upozornil na to už pan Malý – ono je sice pěkný dát lidem tu možnost. Ale když nemají, kde si to jednoduše a za levný peníz nasadit, tak to je dost bezzubá kobyla. Kolik je hostingů pro ASP.NET, který jsou zadarmo?

Aleš Roubíček

Asi dost http://www.google.cz/search?q=asp.net+free+hosting. Otázka je, kolik jich je v česku a to už je o dost smutnější podívaná.

Tomas Janovsky

Jestli neco skutecne „valcuje“ ASP.NET, rekl bych ze je to spis Ruby on Rails, nez PHP. Pochopitelne zalezi na „segmentu trhu“. Nesmite ignorovat objemove obrovsky segment enterprise aplikaci, ktere vetsinou nejsou prilis videt, ale .NET je v nich temer bezkonkurencni.

Jiří Knesl

A jak ho válcuje? Podle TIOBE je PHP 2* aktivnější než C#, kdežto Ruby 2–3* méně aktivní než C#. (slovo aktivní jsem použil jako náhradu za používaný, ikdyž si uvědomuju v kontextu statistik TIOBE nepřesnost obou pojmů)
Ruby je sice super jazyk, ale PHP je defakto standard a volba č.1 pro vývoj webu. To není žádné zbožné přání, to je fakt podepřený desítkami milionů už napsaných řádek aplikací v PHP, statisíci běžících webů (které musí někdo rozvíjet nebo minimálně udržovat) v PHP, tisíci dostupných hostingů, desetitisíci dostupných vývojářů všech kvalit a cen.
Co se týká enterprise řešení, tak tam mimo Javy, .NETu a 4GL jazyků nemůže být snad o ničem jiném ani řeč.

Martin Malý

Jen technická: „To není žádné zbožné přání, to je fakt podepřený desítkami milionů už napsaných řádek aplikací v PHP“ – mám rád takto podepřené fakty. Jistě se mnou budeš souhlasit, že celosvětově je jazykem č. 1 assembler – řádků v něm napsaných je nepoměrně více než řádků napsaných v jakémkoli jiném jazyce. Nebo uznáš, že poměřovat cokoli „napsanými řádky“ je ryzí dojmologie? Ostatně, nebyl to už Wirth, kdo říkal, že napsaný řádek programu není „vytvořená hodnota“, ale „spotřebovaný zdroj“?

Jiří Knesl

Martine, myslím, že jsem to asi špatně podal. Můj výrok nebyl slovy programátora, ale ekonoma a tak by měl být i chápán.
Pokud podnikám při tvorbě webu, je pro mě PHP jasná volba. Budu mít nejvíc zákazníků, kteří budou chtít udržovat a rozšiřovat existující kód. Budu mít největší výběr programátorů. Budu vybírat z nejvíce vzájemně si konkurujících hostingů.
Stejně tak bych pro Windows vybral .NET a ne Cygwin C++ s wxWidgets nebo Tcl/Tk.
Stejně bych pro megafirmu vybral nějaké 4GL řešení (třeba zrovna skládačku v SAPu).
Stejně bych pro vývoj hry použil C++ a OpenGL nebo Directx a embeddoval bych Lua a ne abych to psal třeba v Pascalu a embeddoval do toho assembler.
Ruby je super, pokud mám startup a hotový tým, můžu si vybrat technologii, nemusím přebírat žádné historické produkty – a tam bych sám asi mnohdy RoR použil.
A ano, může se stát, že najdu super kombinaci technologií, která mi ušetří plno času. Napíšu to v kombinaci 4 technologií, které umím jenom já. Projekt se rozroste a budu potřebovat 5 takových, jako jsem já, pak ještě víc, 50, 500. Najít 500 programátorů a adminů Linuxu, Apache, PHP a MySQL je mnohem snažší, než najít 500 vývojářů a adminů OpenBSD, NGinx, Ruby a MongoDB. Malá výhoda získaná na začátku může být velmi rychle koulí na noze.

Martin Malý

Ptákovina, zde porovnávání čehosi podle počtu napsaných řádků, zůstane ptákovinou, ať ji řekne programátor nebo ekonom. :)
Já to tedy řeknu naplno: Ty jako ekonomicky uvažující tvor si budeš vybírat podle několika hledisek s individuálně nastaveným ohodnocením: Jak drahé bude vyvinout to v jazyce X? Jak drahý bude provoz? Jak drahý bude další rozvoj? Do ceny samosebou započítáváš i faktory jako snadnost či nesnadnost sehnat schopného programátora v tom kterém jazyce. O „vnitřní krásu“ toho kterého projektu jde jen do té míry, do jaké ovlivňuje některé z výše jmenovaných hledisek. O počet řádků v jazyce napsaných nejde vůbec, protože řádky nejsou standardní mírou ničeho smysluplného.

Jiří Knesl

Jako ekonomicky uvažující tvor:
1) nebudu najímat programátory dražší jen proto, že píšou v jazyku X, když můžu dostat podřízené píšící Y s podobným výkonem (jen to není tak fancy)
2) se v businessu zaměřím na jazyk Y, protože existujcícíh klientů pro Y je 1000* víc, než pro X
3) vnitřní krásu budu hledat ve volném čase. trh funguje neúprosně – ušetření nákladů o 5 % ročně se škaredým jazykem mi dá za 10 let 60 % úspory (které když vhodně investuju do růstu, tak toho konkurenta prostě položím)
Řádek PHP je řádek v PHP. nemá smysl je příliš porovnávat s řádkem v pythonu nebo ruby. ale má smysl je brát v potaz, pokud chceš někomu přebrat klienta. A dá se snáze přebírat z 100 000 klientů s weby na PHP než z 1000 s weby v Ruby.

Martin Malý

Míjíme se v základní úvaze, a protože mě to nebaví, tak se zeptám stručně: Co přesně pro tebe představuje „řádek v PHP“ (nebo jiném jazyce)? Čeho je mírou?

Borek Bernard

Asi chtěl říct, že to ukazuje na velikost trhu. Možná :)

Jiří Knesl

Řádek v PHP pro mě představuje zlomek dat definovaný jako 1 řádek nějakou štábní kulturou.
1) musí běžet na nějakém hostingu nebo jako CLI aplikace
2) který musí mít alespoň 1 svého vývojáře, který na něm odstraňuje bugy
3) který musí mít alespoň 1 svého vývojáře, který ho rozvíjí pro nové požadavky
Myslím, že se tady taháme o naprosto nepodstatnou metriku „řádků kódu“, přitom já chtěl jen s určitou uměleckou licencí vyjádřít to, že v PHP bude víc eshopů, než ve všech ostatních jazycích dohromady. Že bude totéž platit o CMS, o blozích o návštěvních knihách a polostatických prezentacích.

Martin Malý

Ach tak. Ale tos měl hovořit nikoli o řádcích, ale o aplikacích. Nebo ještě líp – o úspěšných a fungujících aplikacích / realizacích, protože to je to, co jako ekonomicky uvažující tvor bereš v potaz.
Já si totiž, Jiří, nejsem jist, jestli je několik set existujících CMS v PHP dobře nebo špatně – ani z programátorského hlediska, ani z hlediska ekonomického. Je to znamení toho, že PHP je plodné a že naplní jakékoli potřeby? Nebo to je znamení toho, že v PHP si svůj CMS napíše každý matla, dá ho na web a že z těch stovek existujících CMS je tak dvacet, co vůbec stojí za řeč a pět, co stojí za úvahu? Je to dobré, nebo špatné? A co to říká o jazyce a jeho vývojářích?

Jiří Knesl

Když Rasmus Lerdorf uváděl PHP, označil to za „něco v čem napíšeš návštěvní knihu za 3 minuty“. Jestli je to dobře? Ale jisteže! Neumím si představit lepší začátek programování pro nováčka, než mít za 3 minuty hotovou miniaplikaci s naprosto minimálním penzem vědomostí. Nováček by neměl 3 minuty vytvářet třídy, 30 minut psát testy a kód, 30 minut zjišťovat, proč „nejde sestavit war a deploynout do aplikačního serveru“. To není motivační ani didaktické.

Martin Malý

Tím jsi hezky odpověděl na otázku zda PHP použít jako jazyk pro nováčky. Ne na to, jestli v něm postavit firemní aplikaci. Nezlob se, ale při rozhodování o tom, jakou technologii použít pro vývoj aplikace, je fakt, že jazyk motivuje nováčky a jeho používání je snadné zcela irelevantní, s jedinou výjimkou, a tou je situace, kdy chceš vyvíjet aplikaci coby společné dílo nováčků.

Jiří Knesl

Dobře. Pokud budu vyvíjet CMS, budu myslet na to, aby:
1) klient si to mohl nahrát tam, kam potřebuje
2) aby to komunikovalo s prezentací, kterou už má (a co naplat – nativní komunikace bývá jen málokdy méně výkonná a snadná, než SOAP apod.)
3) jsem vyvinul CMS s miniálními náklady (tedy ideálně cena 0 za server sw, 0 za IDE vývojářů, 0 za verzovací sw, co nejméně za vývojáře)
Co myslíš, jak dělám pro někoho jednorázově web? Zadám to na webtrh, tam to někdo za 500 nabuší i s designem, já si to za 2 hoďky opravím a nebo si najmu programátora v ruby, který má 500 na hodinu práce?

Martin Malý

Ono je mi vcelku šumák jak ty děláš web. :) Otázka, kvůli které jsem se do téhle debaty pustil, byla jiná – pokud si to dohledáš, tak zjistíš, že mě zaujala tvá podivuhodná metrika v řádcích, ze které jsi vyvozoval něco o jazycích. Jestli ti tedy rozumím dobře, tak tvé základní hledisko, když to vezmeme s troškou nadsázky, je, jestli v daném jazyce umí pracovat Indové, kterým platíš 0,30USD na hodinu. Což je zcela legitimní hledisko, a dovedu si představit, jakou paniku vzbudí v pánech programátorech zjištění, že takto uvažuje čím dál víc zadavatelů práce. :)

Jiří Knesl

Offtopic: Naneštěstí páni programátoři nejsou zároveň pány manažery. Všiml jsem si totiž, že existují 2 hlediska na kvalitu:
1) programátorský pohled – nejlepší programátor je ten, který odevzdává nejkvalitnější kód bez ohledu na objem.
2) ekonomický pohled – nejlepší programátor je ten, který odevzdává kód minimálně předem dané jakosti (která by měla být vysoká) a dosahuje maximálního objemu.
Nejlepší programátor mezi programátory (macho který zná nejvíc „sortů“, „návrhových vzorů“ a „instrukcí X86“) a nejlepší programátor pro své šéfy a klienty (macho, který ví jak nejrychleji „nahrát soubor“, „nejrychleji udělat přístupnou šablonu v html“, „opravit png pro ie6“) není totéž. Jakkoliv se sám snažím zařadit do 1 a dělat věci, jak se dělat mají, jako zákazník si najímám striktně 2 a s 1 jen konzultuju a ladím detaily.

nobody

Podle mne je skutečný mistr programátor takový, který plní oba požadavky více méně současně (ekonomický i technický) – je schopen v nejkratším čase schopen nabušit kód co nejlíp plnící danou úlohu a zároveň ho vymyslet tak, aby jeho další rozšiřování v rámci zadané úlohy nebylo drahé a komplikované s ještě k tomu nezkurvit zabezpečení.

Počet řádků je irelevantní.

Přehlednost a krása kódu je důležitá jen do té míry, aby se v tom vyznal i někdo jiný a nekomplikovalo to změny v programu.

Použitý jazyk je důležitý. Ale ani ne tak kvůli technickým vlastnostem (pokud příliš neprodražují vývoj = je snadné v něm plnit zadanou úlohu), jako spíš z hlediska ceny, např. chci-li tutéž aplikaci nasadit na další stroj, nesmí to stát zbytečně moc peněz, ideálně jen hardware, co M$ software obvykle nesplňuje.

Vždy to je kompromis. Nikdy nic nemůže plnit všechny požadavky na 100%.

Radek

Zkouším Lightswitch a přijde mi to hodně splašený. Chápal bych, kdyby si MS vzal za vzor vzpomínaný Access a trošku ho zmodernizoval o .NET a ujednotil podporu databází ale tohle vypadá na pořádnýho kočkopsa.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.