it-swarm-eu.dev

Jak kódovat rychleji (bez obětující kvality)

Několik let jsem profesionálním kodérem. Komentáře k mému kódu byly obecně stejné: píše skvělý kód, je dobře otestován, ale může být rychlejší .

Takže Jak se mohu stát rychlejším kodérem bez obětování kvality? Kvůli této otázce omezím rozsah na C #, protože to je hlavně to, co kóduji (pro zábavu) - nebo Java, což je v mnoha ohledech dost podobné.

Věci, které už dělám:

  • Napište minimální řešení, které vám práci udělá
  • Napište spoustu automatických testů (zabrání regresím)
  • Napište (a používejte) opakovaně použitelné knihovny pro všechny druhy věcí
  • Používejte dobře známé technologie tam, kde fungují dobře (např. Hibernace)
  • Použijte návrhové vzory tam, kde se hodí na místo (např. Singleton)

To vše je skvělé, ale nemám pocit, že se moje rychlost v průběhu času zvyšuje. Já se starám , protože pokud mohu udělat něco pro zvýšení své produktivity (dokonce o 10%), je to o 10% rychlejší než konkurence. (Ne, že bych nějaké měl.)

Kromě toho jsem od svých manažerů neustále dostával tento údělek - ať už se jednalo o vývoj Flash v malém měřítku nebo vývoj podnikových Java/C++.

Edit: Zdá se, že existuje spousta otázek o tom, co myslím rychle a jak vím, že jsem pomalý. Dovolte mi to objasnit několika podrobnostmi.

Pracoval jsem v malých a středních týmech (5-50 lidí) v různých společnostech na různých projektech a různých technologiích (Flash, ASP.NET, Java, C++). Pozorování mých manažerů (které mi přímo řekli) je, že jsem „pomalý“.

Součástí toho je, že značné množství mých vrstevníků obětovalo kvalitu za rychlost; Napsali kód, který byl buggy, těžko čitelný, těžko udržovatelný a obtížný pro psaní automatických testů. Můj kód je obecně dobře zdokumentovaný, čitelný a testovatelný.

Ve společnosti Oracle bych soustavně řešil chyby pomaleji než ostatní členové týmu. Vím to, protože bych za tímto účelem obdržel komentáře; to znamená, že jiní (ano, starší a zkušenější) vývojáři mohli dělat svou práci v kratším čase, než mi trvalo, téměř ve stejné kvalitě (čitelnost, udržovatelnost a testovatelnost).

Proč? Co mi chybí? Jak se k tomu mohu zlepšit?

Můj konečný cíl je jednoduchý: pokud dokážu dnes vyrobit produkt X za 40 hodin a mohu se nějak vylepšit, abych mohl vytvořit stejný produkt za 20, 30 nebo dokonce 38 hodin zítra, to je to, co chci vědět - jak se tam dostanu? Jaký proces mohu použít k neustálému zlepšování? Myslel jsem, že se jedná o opakované použití kódu, ale zdá se, že to nestačí.

148
ashes999

Líbí se mi přístup Jeffa Atwooda, který najdete zde http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

V podstatě odkazuje na pasáž z knihy Art & Fear od Davida Baylese a Teda Orlanda. Pasáž jde:

Učitel keramiky v den zahájení oznámil, že třídu rozdělil do dvou skupin. Všichni ti na levé straně ateliéru, řekl, by byli odstupňováni pouze podle množství práce, kterou vyprodukovali, všichni ti napravo pouze na jeho kvalitě. Jeho postup byl jednoduchý: v poslední den ve třídě si přinesl koupelnové váhy a zvážil práci skupiny „množství“: padesát liber hrnců s hodnocením „A“, čtyřicet liber „B“ atd. Ti, kteří jsou hodnoceni podle „kvality“, však potřebovali vyrobit pouze jeden pot - i když dokonalý -, aby získali „A“. Dobře, přišel čas na třídění a objevil se zvláštní kurs: práce nejvyšší kvality byly produkovány skupinou, která byla tříděna podle množství. Zdá se, že zatímco „kvantitativní“ skupina pilně chrlila hromady práce - a poučovala se ze svých chyb - skupina „kvalitních“ seděla teoreticky o dokonalosti, a nakonec neměla více než co dokázat za své úsilí než grandiózní teorie a hromada mrtvé hlíny.

V zásadě se vaše ruce špiní rychleji a častěji zlepšuje vaše dovednosti, než trávit čas studiem a teoretizováním „dokonalého“ způsobu. Moje rada, cvičím, držím krok s technologií a studiem designem.

160
chrisw

Jednou z možností, o kterých se zdá, že nikdo jiný nezmínil, je to, že se vám daří dobře a že vaši manažeři nejsou moc dobří. Jak měří produktivitu? Mohou vám dát konkrétní příklady nebo je to jen obecné vnímání? Zohlednili ve srovnání s vaší dobou čas strávený opravami práce jiných národů?

Viděl jsem spoustu lidí, kteří dostávají zásluhy za to, že se jim něco podaří, zatímco zbytek jejich týmu opravuje nepořádek, který zanechali.

72
pdr

Většina toho, co si lidé myslí je důležitá, není důležité. Rychlost psaní není důležitá. Rychlejší stroje nebo nástroje nejsou důležité. Nejsme pisatelé ani strojníci. Jsme myšlenka dělníci. Jsme tvůrci rozhodnutí .

Co je důležité, je použití zpětné vazby k neustálému zlepšování vašeho rozhodovacího procesu. Jediným způsobem, jak toho dosáhnout, jako je získání jakékoli jiné dovednosti, je prostřednictvím zkušeností, účelné praxe a nepřetržité zpětné vazby.

  • Práce na vedlejších projektech.
  • Práce na open source projektech.
  • Pracujte s vývojáři, kteří jsou lepší než vy. Spárujte program!
  • Vystavte se novým nástrojům a technikám. Nechte to, co funguje.
  • Provádějte programovací cvičení určená pro trénink vašeho rozhodovacího aparátu *.
  • Sledujte své vylepšení na základě objektivních metrik, jako je rychlost a rychlost defektů, a subjektivních metrik, jako je kvalita kódu a fitness.

Konečně: nezapomeňte, že rychlost bez kvality je zbytečná a naopak. Chcete-li maximalizovat svůj nástroj, najděte rovnováhu mezi těmito napětími.

* http://codekata.pragprog.com/

39
Rein Henrichs

Je docela možné, že ve skutečnosti jste vyzváni k obětování kvality některé pro větší rychlost.

V některých vývojových prostředích1, prostě nestojí za čas navíc vyrobit něco leštěného, ​​když to udělá „jen dost dobře“.


1 - Mám na mysli zejména „interní nástrojářství“, ale pravděpodobně existují i ​​další.

25
Michael Shaw

Zní to, jako byste dělali všechny dobré věci - že vás ve střednědobém horizontu zrychlí, takže není zřejmé, zda jste skutečně pomalí. Jen to opravdu víte. (ale je to velmi reálná možnost - PeopleWare si nárokuje až 10x rozdíl produktivity mezi vývojáři pro stejný úkol).

Mám pro vás nějaké návrhy:

  1. Čas je relativní věc, takže nejde pravděpodobně o vaši skutečnou rychlost, ale spíše o vnímání času, který dáváte. Můžete naznačovat, že to bude trvat týden, ale nakonec utratíte dva týdny, zatímco ostatní mohou utratit 3 týdny ... ale vypadáte jen 1 týden pomalu.

  2. Protože tuto zpětnou vazbu dostáváte často, možná je čas si promluvit se svým nadřízeným a kolegy, aby zjistili, co říkají - od nich se musí toho co učit.

  3. Proveďte párové programování s vývojářem „rychlé kvality“, abyste zjistili, zda můžete zaznamenat rozdíl.

12
Stephen Bailey

Všichni lidé, kteří se ptají, zda jste opravdu pomalí, jsou hloupí. Stát se rychlejším programátorem bez obětování kvality je vždy dobrým cílem bez ohledu na to, jak pomalu nebo rychle už jste. To je můj cíl číslo 1 jako programátor a nikdy se mi to nedělá. Vždy se snažím zrychlit bez obětování kvality, jsem tím posedlý. Zde je to, co pro mě doposud fungovalo v pořadí vstřícnosti a na konci některé experimentální nápady:

1) Nikdy se nepřestávejte učit: Naučte se vše o programování a používání počítačů obecně. Najděte oblasti, ve kterých jste slabí, a naučte se je. I když se zdá, že s vaší prací a C # zcela nesouvisí, garantuji, že pokud ji hledáte, často najdete způsoby, jak ji aplikovat na to, co děláte. Učení je také o zkušenostech, takže nejen čtěte věci, ale vyzkoušejte je a rozšiřujte své dovednosti. Pokud jste na Windows zvyklí, vyzkoušejte Unix nebo naopak. Pokud obvykle chcete používat nástroje příkazového řádku try IDE a textové editory nebo naopak. Pokud slyšíte o nástroji nebo technologii, o které jste dosud neslyšeli nebo o nich mnoho nevím, nevzdávejte se pokušení jít dál. Vyhledej to! Nebojte se myslet mimo krabici a učit se experimentální nové technologie, které ostatní tvrdí, že jsou nepraktické; Právě začínáme poškrábat povrch toho, jak programovat produktivně.

2) Rozdělit projekty: Zkuste rozdělit své projekty na mini projekty. Zkuste vydat nové vydání každý den nebo maximálně jednou za několik dní. Zeptejte se sami sebe: „Jaké je minimální množství funkcí, které mohu uvolnit, a přesto uvolnit něco, co je užitečné pro uživatele.“ To je dovednost, kterou se naučíte tím, že to uděláte. Možná budete muset přesvědčit své manažery, aby vám to umožnili, ale obvykle budou s výsledky spokojeni docela rychle. Tím si začnete všimnout, že věci, o kterých si myslíte, že jsou pro vaši funkci podstatné, jsou ve skutečnosti další funkce, které lze později vyvinout. To vám a vašim manažerům umožní upřednostnit pouze nejdůležitější funkce namísto všech funkcí souvisejících s funkcí, na které pracujete. To vám umožní myslet rychleji udržováním vaší mysli jasnou a soustředěnou. Budete zase legitimně programovat rychleji. Vaši manažeři nebo alespoň manažeři vašeho manažera také pravděpodobně vnímají, že nyní programujete ještě rychleji, než ve skutečnosti jste, protože vydáváte více vydání. Další velkou výhodou je, že budete mnohem lépe odhadovat, jak dlouho bude trvat dokončení vydání, a vaši manažeři vás za to budou milovat. Protože již provádíte spoustu automatizovaného testování, neměli byste mít žádné problémy s častými stabilními vydáními. Možná však budete muset posílit svůj automatizovaný systém sestavení. Velmi doporučuji přečíst knihu Continuous Delivery v řadě Martin Fowler. Je to těžko čitelné a protože je velmi opakující se, ale stále velmi užitečné.

3) Použijte techniku ​​pomodoro a přizpůsobte/změňte, co pro vás nefunguje. Pokud to zkombinujete s číslem 2 na tomto seznamu, získáte obrovskou podporu produktivity.

4) Naučte se Vim. I když nakonec tyto příkazy použijete ve Visual Studio přes ViEmu, nebo z Eclipse přes plugin nebo z Emacsu, získáte produktivitu. Nejlepší způsob, jak se naučit Vima, je začít ho používat a donutit se k tomu, aby nikdy (deaktivoval/nevrátil se ke svým starým nástrojům), dokud jej nezvládnete. Zpočátku je to bolestivé, ale nikdy nebudete chtít ustoupit a dokonce se krčit, když budete muset pracovat bez něj. Někdo by řekl, že to nezvýší vaši rychlost o moc. Ale rychlejší je rychlejší, zvláště když čtení a úprava kódu je CO JE WE DO, a zjistil jsem, že s tím občas ušetřím spoustu času.

5) Tento poslední není nutně doporučován, protože si nejsem jistý, že je to dobrý nápad, a ve skutečnosti to může snížit vaši produktivitu, ale stejně to tam projdu. Můžete zkusit provést více akceptačních testů a méně jednotkových testů, nebo možná alespoň se ujistit, že provedete nějaké akceptační testy. Měl jsem úspěch se SpecFlow, ale mám podezření, že tam je něco lepšího. Dokonce i psaní specifikací může být docela technické, takže možná budete chtít, aby váš manažer/zákazník nejprve napsal hrubou verzi, která se výrazně změní, nebo můžete celou věc napsat sami a nechat si ji přečíst a OK. To vám pomůže s číslem 2 z tohoto seznamu. Také akceptační testy mohou být praktičtější a vyžadují méně kódu než testy jednotek. To neznamená, že je nahrazují, různé nástroje pro různé věci. Pokud však provedete hodně akceptačních testů, můžete se dostat pryč s menším počtem jednotek.

6) Tento je ještě více experimentální a kontroverzní. Vlastně jsem to neudělal sám, takže to nemohu přesně doporučit. Naučte se používat programovací systém Meta od společnosti JetBrains. Použijte jej k vytvoření nástrojů, které váš manažer/zákazník používá k vytvoření požadovaného softwaru sám. Možná budete moci přestat dělat testy jednotek a přejímky, pokud to můžete použít k vytvoření nástrojů, které váš manažer/zákazník používá k upřesnění chování velmi přímým a nekonfliktním způsobem. Záměrem není zbavit se programátora. Programátoři by stále potřebovali přidat nové funkce k těmto nástrojům používaným zákazníkem/manažerem, kdykoli (lidé, ne nástroje) nemohou snadno vytvořit nějakou požadovanou funkci. Věřím, že MPS nebo jiné podobné nástroje jsou cestou budoucnosti.

8

Ve skutečnosti to, co se scvrkává, je zážitek. Chcete-li být rychleji v tom, co děláte, je to jako řídit auto, zpočátku se bojíte, protože jiní jsou rychlí (nebo opilí) řidiči (nebo obojí) a chcete se bezpečně dostat domů (z hlediska softwaru, chcete se ujistit, že váš kód funguje tak, jak bylo vyvinuto a funguje dobře).

V průběhu let/měsíců, jakmile se dostanete na závěs jízdy a dálnic, se naučíte několik triků na cestě, která dělá vaši jízdu zábavnou. Tomu říkáme zážitek. Ty „triky“ (které nazývám znaky) jsou tím, co pomáhá.

V mém případě jsem se naučil skutečné použití návrhových vzorů kódováním (dokonce @ home) a naučil se používat některé. Když se tedy setkám s problémem, který vyžaduje designový vzor, ​​využiji minulé zkušenosti, abych zjistil, které fungovaly a proč by to fungovalo/nefungovalo pro mou situaci.

Celkem:

  • Zkušenost vytváří vlastnosti, které zvyšují důvěru a lepší software.

PS: Zkušenost také pochází z učení od ostatních. Např. Pomoc od SO, párového programování, vzájemných hodnocení atd. Nemůžete mít zkušenost, pokud se nemůžete ohlédnout zpět a poučit se z chyb (nebo pokud někdo nikdy nezpochybní vaše úsilí).

8
Buhake Sindi

Otázka zní, zda jste levnější, když se podíváte na dlouhodobé celkové náklady.

Jinými slovy, jsou vaše pečlivě vytvořené opravy chyb tak vysoké kvality (včetně testovacích případů a dokumentace), že převáží náklady na nutnost udržovat opravy chyb provedené vašimi rychlejšími spolupracovníky?

Pokud ano, musíte o této skutečnosti informovat své nadřízené. Může být obtížné argumentovat, pokud opatření neměří a nemá potřebné údaje k potvrzení vašeho hodnocení.

Pokud ne, pak musíte důrazně zvážit proč to je tento případ:

  • Jste příliš nezkušení?
  • Trávíte hodně času tím, že děláte věci, o něž se nepožádáte a které by podle vás měly být?
  • Máte potíže s určením, kdy je oprava hotova?
  • Je váš kód koneckonců nižší kvality, než si myslíte?
  • Měli byste přistupovat k vývoji kódu jiným způsobem, protože to trvá příliš dlouho, než se zrychlíte tak, jak to děláte nyní?
  • Strávili jste příliš mnoho času na věcech, jako je tento web?

Přemýšlejte o tom a upravte svou otázku podle svých zjištění.

8
user1249

Využijte více mozku a méně testujte. Upřímně řečeno, testování má své místo, ale je to drahé.

Přečtěte si také The Art of Unix Programming (zdarma online, kniha za cenu)

Nakonec možná nebudete na správném místě. Kulatý kolík ve čtvercové práci atd.

Nakonec je to jako škola: „Výstup, co chce učitel“, se stává „výstup, který vedení požaduje a platí“.

5

Pokud vezmete velký, hotový projekt a získáte počet „konečných“ řádků kódu za hodinu na hodinu, zjistíte, že programátoři kód MUCH pomaleji, než jste si dokázali představit.

Mluvíme jen pár řádků kódu denně. Zbytek času trávíte ladením, přepisováním a děláním věcí obecných programátorů.

Možná jste slyšeli staré přísloví - pokud při psaní narazíte na chybu, ušetří se vám 10krát více času, pokud jste ji zachytili v době sestavení, což je 10x lepší než zachycení během QA, což je 10x lepší než chytit po vydání ..

Jak to zrychlíte? Nesoustředil bych se na žádnou formu psaní rychlostí - snížení chyb a zlepšení dalších „budoucích interakcí“ s vaším kódem by mělo být mnohem lepší investicí vašeho času.

Čitelný, jasný kód je kritický. Kód napíšete jednou, ale přečte se několikrát. Zápis pro čitelnost vám ušetří spoustu problémů po řádku (což také ušetří spoustu času). Pokud se VŽDY vrátíte a přečtete si svůj kód a musíte na něj chvilku promyslet, pak to děláte špatně.

Párové programování může zkrátit čas QA, a pokud uvažujete, že jeden programátor produkuje jen několik řádků denně, pokud dva mohou kódovat stejnou rychlostí jako jedna, ale s menším počtem chyb, pak jste ZPŮSOBNÍ.

Defenzivní kódování (například kontrola parametrů) může snížit problémy ... Pokud máte ve svém týmu opravdu dobrého analytika/architekta, můžete ušetřit čas díky dobrému počátečnímu návrhu.

V opačném případě jen vylepšujte své designové dovednosti. Když získáte zkušenost, ocitnete se více schopni rozeznat vzorce, které nebudou fungovat, a vyhnout se jim, budete moci včas identifikovat potopy atd.

5
Bill K

Pokud vím, je to:

  1. dobrý
  2. rychle
  3. levný

Jako manažer si můžete vybrat libovolný 2.

Nedělejte si starosti s komentáři, které jste nabrali na rychlosti. Jako spoluzakladač bych raději udržoval kód, který je dobře promyšlený a dobře napsaný, než něco, co bylo pohromadě.

3
Nico

Zvážili jste při práci podrobný audit sebe sama? Buď perem a papírem sledujete, jak trávíte čas, nebo použijte něco jako Rescue Time ke sledování sebe.

Jakmile si více uvědomíte, jak přesně trávíte čas, můžete získat lepší představu o tom, co je třeba zlepšit, a soustředit své úsilí tam.

V ideálním případě můžete vyzvat některé ze svých spolupracovníků, aby to také udělali, porovnat své výsledky a získat nápady od sebe navzájem. Pravděpodobně máte nějaké silné stránky, z nichž by mohli těžit také.

Možná zjistíte, že trávíte příliš mnoho času částmi vašeho procesu, která by mohla být automatizována, nebo jen že máte v určité části dne mnoho rozptýlení a další část dne je tichá, pak si můžete naplánovat své úkoly to atd.

Nebo možná zjistíte, že testování zabere více času, než jste si mysleli, a musíte přehodnotit své vnímání, že vás zrychluje.

Pokud nic jiného, ​​nedává vám určitá měřítka, proti kterým můžete pracovat.

3
DKnight

Z vašeho seznamu si vede dobře.

Pokud vaši kolegové dělají kód s vyšším číslem CRAP, půjdou rychleji. CRAP je komicky pojmenovaná metrika kombinující cyklomatickou složitost a testovací pokrytí.

Nepište kód, který je více CRAP, než musíte. ;)

Moje jediná změna, kterou navrhuji, je používání knihoven, nepište je, pokud:

  1. Vaše společnost prodává knihovny
  2. Opakovaný kód jste refakturovali do knihovny

Čtete a děláte, a to je skvělé. Ale možná byste uvízli nad progresivním nebo OO kódem, vystavili jste se funkčnímu programování (řekněme Haskell?) A Prologu?

Chcete-li zaostřit OO techniku ​​programování), hráli jste s Smalltalk/Squeak?

A konečně, teorie. Máte alespoň základní znalosti teorie grafů? (Některé programy pracují se stromy, DAGy nebo jen prostými grafy. Sítě jsou grafy)

3
Tim Williscroft

Budu citovat Strýček Bob :

Jediným způsobem, jak jít rychle, je jít dobře.

Pokaždé, když yeild na pokušení obchodovat kvalitu pro rychlost, zpomalíte. Pokaždé.

-- „vehementní průměrnost“, Robert C. Martin

3
Johnsyweb

Mám námitku proti pohledu „obětované kvality pro rychlost“ OP.

Profesionální programátoři (programátoři) musí uspokojit 3 objekty:
1) Kód by měl běžet podle plánu
2) Dodání by mělo být včas
3) Mají dobrou kvalitu, dokumentaci atd.
4) Jiné atd.

Myslím, že OP byl obviňován jako pomalý pravděpodobně proto, že OP neudělal včas.

2
9dan

Toto je úlovek 22, který je těžké obejít. I když vám stále mohou chybět zkušenosti a určité množství znalostí v mnoha aspektech již jsou rychlejší než většina ostatních, úlovek je, že je těžší měřit.

Osobně nejlepší, co v této chvíli můžete udělat, je změřit se. Poskytněte si zpětnou vazbu o tom, jak pracujete. Snadné změny ve vašich pracovních návycích vám mohou zvýšit produktivitu.

Zjistil jsem, že e-maily jedly daleko víc, než jsem si myslel jednoduše kvůli přerušení. Nyní odpovídám na e-maily pouze dvakrát denně a za několik dní jsem získal téměř 1 hodinu produktivity. Vyzkoušejte metody jako pomodoro , použil jsem to jako prostředek k měření. V pravidelných intervalech (15 minut) bych si poznamenal, co jsem tehdy dělal. To mi umožnilo vidět, jak byly moje dny strukturovány a co jsem mohl udělat, abych maximalizoval účinnost.

2
Newtopian

Hlavní věci, na které mohu myslet, jsou následující

  • Zvyšte rychlost psaní.
  • Používejte nástroje, které zvyšují produktivitu. Například ReSharper.
  • Rychlejší stroje nebo nástroje. Jako více RAM nebo jednotka SSD).

Jsem si jistý, že v oblasti kódovacích dovedností můžete dělat i některé věci, ale zní to, jako byste se zabývali všemi podobnými věcmi. Věci, které jsem uvedl výše, vývojáři obvykle přehlíželi.

2
mpenrow

Mohli byste absolvovat kurz rychlého psaní. Nevím, jestli je psaní rychlejší, ale „příliš pomalé kódování“ může být způsobeno jednoduše pomalými rychlostmi psaní.

A co generátory kódu? Někdy se kód opakuje. Refactoring může některé z nich odstranit, ale i tak můžete mít opakovaná volání na stejnou refactored funkci. V závislosti na datech a kódu, se kterým pracujete, mohou generátory kódu (napsané v Excelu, Perlu, Javě atd.) ušetřit spoustu času . A použití nástrojů pro generování kódu pro vývoj uživatelského rozhraní je obvykle neomylné.

A konečně, možná metriky jsou špatné. Uvažovali jste o tom, že kódujete co nejrychleji rychlým nastavením, protože všechno ostatní a že časové osy jsou příliš krátké, což vás vypadají jako pomalý kodér?


Na základě úprav ve vaší otázce se zdá, že byste mohli buď vzít cestu některých vašich spolupracovníků a společně hacknout nejrychlejší řešení, které bude fungovat - a dokumentace a QA budou zatraceny!

Nebo ... získejte více zkušeností a praxe v konkrétní oblasti, abyste dobře znali kódovou základnu a API, abyste mohli řešení kódovat ve spánku. To lze provést, ale vyžaduje více času. Pokud jsou ostatní vývojáři, kteří jsou rychlejší než ty, o kterých je známo, že jsou starší a zkušenější, pak musí udělat jen jednu věc - vy se musí stát starší a zkušenější!

Výhoda Squeak pro rychlé kódování jde daleko za pouhé „honování něčího OOP= dovednosti.“) Existuje důvod, proč moderní GUI, stejně jako IDE, byly vynalezeny na Smalltalk, nemluvě o tom, že JUNIT byl portem SUNIT to Java, termín „OOP“ byl vynalezen k popisu Smalltalk atd. Atd.

Člověk musí vždy používat jazyk a prostředí, které nejlépe vyhovuje tomu, co člověk doufá, ale přinejmenším pro obecné prototypování bych se s tím vrhl na cokoli, s možnou výjimkou HyperCard, a dokonce by to vyžadovalo benchmarking, abychom viděli, která byla ve skutečnosti rychlejší vzhledem k tomu, že v Squeak jsou zabudována zařízení podobná hypercardům.

0
user22340