Mi a tapasztalata a Pony programozási nyelv használatával kapcsolatban?

Legjobb válasz

Programozó vagyok a Wallaroo Labs-nál (www.wallaroolabs.com), ahol jártunk a Pony felhasználásával a Wallaroo, az adatfeldolgozási keretrendszerünk. Részt veszek a Pony fordítójának munkájában is.

A Pony nagyszerű nyelv volt a Wallaroo-val való munkához. A típusú rendszer kiküszöböli az olyan problémákat, mint a null pointer hibák, így biztosak lehetünk abban, hogy ha programunk lefordítja, akkor nem fog összeomlani. A referencia képességek garantálják, hogy programjaink egyidejű részei mentesek legyenek az adatversenyektől. A fordító gyors kódot generál, a színészenkénti szemétgyűjtő pedig kiszámíthatóan alacsony farok késleltetéseket ad számunkra. Mindezek együttesen lehetővé tették számunkra, hogy egy nagy darab szoftvert készítsünk, amely az elvárásoknak megfelelően viselkedik.

A Pony kissé megfélemlítő lehet a kezdők számára a típusellenőrzés és a referencia képességellenőrzés miatt. A legtöbb Pony programozó bizonyos mértékig küzd ezekkel a dolgokkal, amikor elkezdi használni a nyelvet, és a kis egyszereplős programok esetében túl nehézkesnek tűnhetnek. Ezek a dolgok azonban értékessé válnak, amint a programod mérete és összetettsége növekszik. A típusrendszer garantálja, hogy a program nem fog összeomlani, mert egy objektum nem a várt típusú volt. A referencia képességek kiküszöbölik az adatversenyeket, amelyeket köztudottan nehéz elkapni a tesztelés során, és nagyon fájdalmas a hibakeresés. Nem feltétlenül fogja értékelni ezeket a dolgokat, amikor pezsgő hangot ír, de ezek a különbségek a siker és a kudarc között, amikor olyan bonyolult szoftverrendszereket építenek, amelyekre a vállalkozások épülnek.

Szerintem Pony édes spot nagy eseményvezérelt alkalmazások. Mint korábban említettem, a típusrendszer és a referencia képességek segítenek a bonyolultság kezelésében, és a Pony egy színész rendszeren alapul, amely jól illeszkedik az eseményvezérelt architektúrákhoz. Remekül illeszkedik abba a helyre, ahol esetleg valami olyat használ, mint a Node.js vagy az Erlang / Elixir, de megkapja a típusbiztonság és a natív végrehajtás előnyeit.

A nyelv még mindig új, ezért a standard könyvtár elég minimális más nyelvekhez képest. Ez egyrészt azt jelentheti, hogy Pony nem lesz alkalmas a projektedhez. Másrészt ez azt jelenti, hogy rengeteg lehetőség kínálkozik az emberek számára a közreműködésre.

A Pony-t aktívan fejlesztik a különböző háttérrel rendelkező önkéntesek, ezért nem fenyegeti az elhagyás veszélye, mert valaki elhagyja a projektet, vagy új állást kap. Ez jobb távlati kilátásokat biztosít azoknak a nyelveknek, amelyeket egyetlen személy vagy vállalat tart fenn.

Van egy dokumentumom , amelyet frissítek időről időre véleményem szerint releváns pontokkal azok számára, akik érdeklődnek a Pony megnézése iránt. Olyan dolgokra terjed ki, amelyeket fontosnak tartok.

Általában nagyon örültem a Pony-élményemnek, és arra biztattam az embereket, hogy töltsenek egy kis időt annak ellenőrzésével.

Válasz

Úgy gondolom, hogy a Pony a válasz az Erlang (és az Elixir) összes problémájára – főleg, hogy ezeket a nyelveket még azelőtt tervezték, hogy az emberek rájöttek volna, hogy valóban párhuzamos nyelvet tudsz építeni, anélkül, hogy az összes változót belsőleg körül kellene másolni. annak szükségessége, hogy minden megváltoztathatatlan legyen (a fejlesztőbarát egyidejűség érdekében). Ezek az új ötletek olyan gyorsan tették Pony-t, mint a C ++, de potenciálisan hatalmasak, mint Erlang. Számomra ez az Erlang valóban futurisztikus változata, amit ma valaki megtehetne, ha a semmiből kellene újra feltalálnia Erlangot. A rozsda hasonló, de az ilyen elképzelések primitívebb megvalósításáról vitatkoznék (engedélyrendszerével). A Rust-ban még mindig állandóan gondolkodnia kell a szálakról és más rendszerszintű folyamatkezelési dolgokról, hogy a modern nyelvnek valóban meg kellene oldania az Ön számára. Vagy talán igazságosabb azt mondani, hogy a Rust egy rendszerszintű programnyelv, és a Pony egy szinttel feljebb van ettől, miközben még mindig nagyon gyors.

Sajnos, mert a JP Morgan néhány idióta informatikai vezetője elutasította a szolgáltatásokat tavalyi szerződés a Causality-től (további információ: https://www.linkedin.com/pulse/end-causality-constantine-goulimis ) – a nyelvet fejlesztő cég eredetileg csődbe ment és a legfelsõbb emberek más vállalatoknál dolgoztak.

Az egész Pony-történet mögött a legfontosabb agy Sylvan Clebsch volt, egy nagyon okos CS srác. Láttam a videóit, és ezt valóban le is húzhatta volna (az „Erlang v2” platform készítése, amely modernebb programozási nyelvű tervezési ötletekre épült).

Azok a srácok, akik átvették a Sylvan and Causality céget egyszerűen nincsenek a munkájukon.

Nincs több ragyogás az egész projektben, és az első dolog, amit a projekt átvételekor tettek, az egy magatartási kódex, egy SJW baromság dokumentum közzététele volt. annak meghatározása, hogy miként kell megfelelnie idióta baloldali ideológiájuknak, mielőtt tagja lehetne a kis csoportjuknak.

Ez a szó szoros értelmében a technikai fejlesztések egyike, ahol bizonyos piaci viszonyok miatt a rosszabb megoldás nyert. A másik alkalommal, amikor a Sun a dot-com buborék több milliárd dollárnyi dollárjával forgalmazta a Java-t mindenféle probléma megoldására, amelyre soha nem tervezték.

Egyébként nem hinném, hogy ez lenne valóban használják a produkcióban, kivéve néhány apró kóddarabot itt-ott, de nem egész rendszerként – helyesen, mivel messze nem valósítja meg azt, amit Sylvan és néhány eredeti szerző elképzelt az egész nyelvről (és később elosztott platformról) lenni és csinálni.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük