2015-07-01 калпави технологии
by Vasil KolevАман бе.
В превод, “яжте моето лайно, по-вкусно е от чуждите”, което не променя факта, че си е лайно. Идея си нямам откъде е това желание на двете общности да се сравняват, и особено рубистите да се чувстват много велики в сравнение с PHP, при условие, че и двата езика са играчки, на които заблудени деца се опитват да пишат големи неща и после дълго време страдат. Единствената причина все още да няма толкова много некадърен код на ruby е, че просто не са мигрирали достатъчно от маймуните, дето пишат на php натам, после резултатът ще е същия.
А защо не изхвърлим mindset-а, че “технологията, дето беше модерна докато бях млад е най-хубавата”, не разучим какво има и не ползваме подходящото нещо за подходящата цел? Хора, дето трябва да учат другите на програмиране трябва да дават някакъв хубав общ поглед, не да забиват в конкретни технологии.
Колкото до това, че и двете са играчки – за php няма нужда да го обяснявам, за ruby – в наши дни да направиш нещо толкова гигантско, тромаво, single-thread-нато (да, знам за мижавите опити да се направи нещо я с fiber-и, я с thread-ове и колко много не работят) и като цяло с инфраструктура и технологии от преди 15 години си е жалко. Може да се види като цяла система go, което е изчистено, паралелизирано както трябва, не особено голямо и доста бързо, или lua, като чист и ясен език, който може да се интегрира някъде.
Та, накратко, може би е добра идея програмистите да мислят за програмиране (и свършване на работа), не за мерене на пиш^Wтехнологии.
Tags: идиоти, овча мисъл
July 1st, 2015 at 18:44
Нямам несъгласие с теб в това отношение, просто съм тук, за да ти кажа, че go е зверски неконсистентен език, който има някакви ужасни проблеми и community, което basically казва “нямаме проблеми”. Ето ти някакво по-широко мнение: https://news.ycombinator.com/item?id=9267211.
Що се отнася до lua, той е толкова минималистичен, че, когато аз се рових в него, нямаше модулна система (requires/imports), единствено някакъв начин за сегментиране на глобални неща с някакво метапрограмиране. Можеше спокойно да си напишеш модулна система… аз видях поне три различни в различни проекти. Имах нужда от “split” метод за string. Няма такъв. Но намерих статия в уикито, която обясняваше как да си напишем. Имаше над 10, всичките с разнообразни предимства и недостатъци. Lua е език, който се използва за скриптиране на игри заради ниския overhead. Не мисля, че го използват, защото го харесват. Мисля, че го използват, защото е единствения vaguely high-level език, който е достатъчно бърз, за да може да се ползва за игри :).
Просто казвам тия неща, за да наблегна, че *всичко* е зле. Някои неща са по-малко зле от други неща, за определени цели. А причината да ползваме какъвто и да е език (или технология, или операционна система) е защото сме го научили и ни е харесал, и знаем как да му заобикаляме по-шитавите части :).
July 1st, 2015 at 20:37
Напълно съгласен с теб, че технологията няма значение. Боза можеш да направиш и с двете. С PHP едни бози стават по-лесно, с Ruby други. Има някои добри практики, към които Ruby те тласка и учудващо, други, към които PHP те тласка. Не бих ги нарекал еднакви (определено смятам, че Rails е напред в много аспекти, включително и до каква степен помагат на начинаещи да стигнат до качествен), но и не смятам, че някое от двете е магическо решение.
Тръгнах да пиша, защото намирам за сладко, това че ги наричаш играчки, защото не ти отговарят на изкувствените критерии. Все едно аз да кажа, че Go/C/Lua са играчки, щото нямат добър web framework дето те прави продуктивен както Rails или Symfony. Или пък са играчки, щото нямат добра CMS система като WordPress.
С други думи, силно ме забавлява как храниш едно тъпо изказване и веднага след него правиш друго :)
July 1st, 2015 at 21:23
@Стефан, http://leafo.net/lapis/ , https://revel.github.io/ , за cms-и и сам може да потърсиш.
Играчки са, защото всичко по-голямо, направено на тях и на по-голямо натоварване почва да умира ужасяващо. Критерият не е изкуствен, критерият е “какво може да работи за реално натоварване за целия свят” :)
July 1st, 2015 at 23:46
Аха.
На сайта на Revel пише, че е high-productivity, значи определено е сравнимо с Rails. Пък Lapis има версия, дето започва с цифра, различна от нула. Няма какво да гледаме success story-та, community или не дай си боже де се опитаме да направим нещо с тях – щом можем да ги намерим с Google, значи са в играта.
Иначе, ей сега отивам да пиша на GitHub и на Basecamp, че нямат реално натоварване за целия свят. Сигурно ще са ентусиазирани от идеята да пренапишат системата си на Lua.
Но да, оценявам идеята да храним едни технологии и възхваляваме други, без да имаме съществен опит с тях. В крайна сметка, явно нито са важни детайлите, нито е важно да виждаме цялата картинка. Напълно достатъчно е да си харесаме по една повърхностна причина е да почнем да храним и да хвалим.
Бих се опитал да ти намеря цитрам блог пост, който критикува такова мерене на пиш^Wтехнологии, но уви, не мога да намеря добър такъв.
July 2nd, 2015 at 00:01
А това да наречеш Ruby “single-threaded” показва шокиращо неразбиране както към нишките, така и към Ruby. Бих се опитал да те образовам в тая насока, ама мисля, че демонстрираш ясен тренд на “чукча писател, чукча не читател” и няма да чуеш.
Поне добре си тагнал тоя блог пост като “овча мисъл”.
July 2nd, 2015 at 00:15
Ползването на Ruby, PHP, дебели framework-ове и всякакви такива неща е в категорията “насърчавам конкуренцията ми да го прави”.
По темата за single-thread-ността на ruby, for all intents and purposes така се получава, гигантски thread-ове/child-ове/квото е там, които омазват share-натата си памет (т.е. пишат по нея и им се появява копие) и страдат от един проблем, дето slashdot го имаха с mod_perl през 90те години. Голяма част от целта на thread-ването е да има споделяне на ресурси, което ако се случваше както трябва, нямаше да има случки като ей-тия https://speakerdeck.com/sfalcon/how-we-moved-hosted-chef-to-erlang-mysql-and-why-you-didnt-notice или тия http://blog.parse.com/learn/how-we-moved-our-api-from-ruby-to-go-and-saved-our-sanity/ , без да броим “културата” на ruby, която е една от най-гнусните по отношение на нормално deploy-ване и доведе debian-ци до момента да теглят една майна на цялото нещо.
Иначе, по същия начин може да се каже същото нещо и на dropbox, които за да успеят да си оптимизират кода, накрая наеха Гуидо. Python по никакъв начин не е език, който става за такива неща, ама инерцията понякога е непобедима, и доста от тия хора им се иска да са почнали на нещо друго (или да е имало нещо друго, което да могат да ползват).
July 2nd, 2015 at 00:20
@Andrew, по темата луа – ние го ползвахме в pcloud, и в общи линии написването на stdlib за нашите цели не отне повече от месец (като се писа от нулата, понеже на човека му беше забавно да го прави, иначе можеше и да минем по-бързо). Минимализмът му не е колкото на асемблера, т.е. инвестицията във време да го докараш до това, което ти върши работа не е особено голяма.
Иначе, като знам за какви игри се е използвал поне в началото и за каква част от логиката, там в общи линии всичко би свършило работа (quest-овете не са кой-знае колко cpu intensive). Самият език никак не е лош :)
July 2nd, 2015 at 00:34
> По темата за single-thread-ността на ruby, for all intents and purposes така се получава, гигантски thread-ове/child-ове/квото е там, които омазват share-натата си памет (т.е. пишат по нея и им се появява копие) и страдат от един проблем, дето slashdot го имаха с mod_perl през 90те години.
За нишки ли си говорим сега или за процеси? Къде в нишките има копие на памет? Сигурен ли си, че въобще знаеш за какво говориш? Щото не ме оставяш с такова впечатление.
> Голяма част от целта на thread-ването е да има споделяне на ресурси, което ако се случваше както трябва, нямаше да има случки като ей-тия […]
Прегледах и набързо двата линка и това, до което стигнах, е че проблемите им идват от много процеси, а не от много нишки (начина, по който работят Unicorn, passenger и т.н.). Това няма нищо общо с хипотетичата еднонишковост на Ruby.
Мога да си обясня тоя ти гаф по два начина. Или не правиш разлика между нишки и процеси или нямаш никаква представа за какво говориш, а само набор от повърхностни впечатления. Ще ти дам кредит и ще приема, че е второто.
> Иначе, по същия начин може да се каже същото нещо и на dropbox, които за да успеят да си оптимизират кода, накрая наеха Гуидо. Python по никакъв начин не е език, който става за такива неща, ама инерцията понякога е непобедима, и доста от тия хора им се иска да са почнали на нещо друго (или да е имало нещо друго, което да могат да ползват).
Има разлика между “не става за такива неща” и “играчка”. Лесно би ме навил, че Ruby не е подходящ за имплементацията на целия Dropbox. Може би части от него, но едва ли всичко. Не знам. Не съм писал Dropbox, нямам дълбоко разбиране на проблемите. Обаче да го наречеш играчка заради това… не, съжалявам. Грешиш.
July 2nd, 2015 at 11:18
ОК, ако го схващаш по-лесно – Ruby е език за прототипизация, като python. Върши работа да напишеш бързо нещото, но в момента, в който имаш голямо натоварване, става твърде скъп за поддръжка. Език/framework, който яде по около 100mb на паралелен connection звучи като писано от хора, казали си “Я да видим дали не можем да бием java-та по алчност”.
Другата причина, поради която не е подходящ за какъвто и да е сериозен production от debian го обясниха едно време, заради нестабилната среда и community, което смята за правилно всичко да се ползва от git HEAD-а.
July 2nd, 2015 at 12:14
Не се заяждайте, програмисти. :P
July 2nd, 2015 at 13:13
Чакай да видим дали те разбирам правилно.
> ОК, ако го схващаш по-лесно – Ruby е език за прототипизация, като python. Върши работа да напишеш бързо нещото, но в момента, в който имаш голямо натоварване, става твърде скъп за поддръжка.
Това го казваш на базата на (предполагам) нулевия ти опит в търкалянето на Ruby/Python неща и в лицето на немалко контрапримери (GitHub, Basecamp, Quora, YouTube). Имам сериозни съмнения, че ти си credible source по въпроса колко лесно се поддържа Python или Ruby. Имаш ли някакъв, на който се позоваваш, където някой споделя реален опит с достатъчно детайли, или всичко на което базираш мнението си са две презентации защо някой си е тръгнал от Unicorn?
> Другата причина, поради която не е подходящ за какъвто и да е сериозен production от debian го обясниха едно време, заради нестабилната среда и community, което смята за правилно всичко да се ползва от git HEAD-а.
Т.е., няма значение, че не ползвам debian в production, щом от debian са казали нещо, значи то е вярно и аз трябва да си сменя технологиите, така ли?
—
Сериозно, тоя bullshit от същия човек ли идва, който се оплаква от липсата на критична мисъл около него?
July 2nd, 2015 at 13:30
Не е защото debian са го казали, а какво точно са казали. Пращал съм ти го, чел си го.
По темата за примерите – http://codefol.io/posts/Why-Ruby-Should-Stay-a-Laughing-Stock . Примерите ти са все хора, които могат да си позволят да хвърлят гигантско количество хардуерни и човешки ресурси, щото са почнали с едно нещо и не смеят да го сменят. Примера с youtube – тия хора все още ползват apache, който е другия пример за нещо, което си е хубаво да си играеш, но търкалянето му в production с голямо натоварване иска огромни еквилибристики (може да накараме Мариян да направи лекция по темата, щото той е също от хората, дето нямат избор и има кило patch-ове за него).
(разбира се, за тях информацията е от 2011, и имайки впредвид, че са в google, не е ясно google колко голяма част от стека им изнася някъде другаде).
Хората стоят на прототипния си език, щото нямат избор – нямат кой да го пренапише, натрупали са огромен codebase и т.н., в общи линии има проблема на Cobol-а :)
Иначе, ако искаш, ще си отделя една седмица и ще ти напиша подробно защо това е език за прототипизация и е вредно да се ползва в production за каквото и да е, което не е малък проект. Не казвам, че е невъзможно, но в един момент ужаса става сравним с това да търкаляш web сайт, писан изцяло на C.
update: C не е добрия пример, може би по-скоро на tcl.
July 2nd, 2015 at 14:23
> и community, което смята за правилно всичко да се ползва от git HEAD-а.
What? Dude, ruby community-то измисли Semantic Versioning (http://semver.org/). Междувременно, препоръчителния начин за инсталиране на Go пакети е чрез `go get `, което тегли master (http://nathany.com/go-packages/, http://zduck.com/2014/go-and-package-versioning/).
И преди да ми кажеш, че има външни tool-ове за Go, които имплементират някакъв свестен versioning, да, има, и са писани от рубисти, които пробват Go. И огромна част от community-то ги храни, щото “go get ни стига, що са ни някакви сложни работи дето работят с версии”.
Стефан може да е трол, ама he’s kind of got a point. Дай го малко по-консистентно с това какво храниш и какво харесваш и защо.
По луа темата мисля, че искам да коментирам на живо, щото дори не знам откъде да започна с твоя отговор :).
July 2nd, 2015 at 21:25
> Стефан може да е трол, ама he’s kind of got a point.
Стефан може да е много неща, но “трол” не е едно от тях. Да си имаме уважението.
—
Иначе, мисля да вдигна ръце от този разговор, щото до нищо смислено няма да стигне. Вече си излях, каквото имах да изливам. От там нататък “Ruby и Python са езици за прототипизиране” е остаряло мислене, принадлежащо на 90те и може би е неправедливо от теб да искам да си по-напредничав в мисленето си.
Само пак ще ти припомня, че не говориш от опит, а от повърхностни наблюдения. Явно ти е достатъчно. Уви, аз имам нужда от повече опит и повече данни, за да твърдя толкова уверено нещо.
July 3rd, 2015 at 03:29
Аз само чета… този път ми стана забавно, повече от друг.
Ключ в изказването на @Васил за мен са относително началото:
“Единствената причина все още да няма толкова много некадърен код на ruby е, че просто не са мигрирали достатъчно от маймуните, дето пишат на php натам, после резултатът ще е същия.”
И относително края: “Та, накратко, може би е добра идея програмистите да мислят за програмиране (и свършване на работа), не за мерене на пиш^Wтехнологии.”
Май никой замесен в тоз спор няма да ги отхвърли – това му беше мисълта на текста… според мен; правилна колкото си искаш, изкриви се работата в процеса на разговора ви.
Нито PHP е цвете (community чудо, само Javascript нещото го конкурира), нито Ruby – най-якия deployment, наистина (трябват ми 100 dev библиотеки в production?!? и компилатори… и процесорно време за билдване на разни неща, и никога не знам какво съм билднал и дали е адекватно; каквото и да ми говорят за semver). Нито Python, нито C.
Във всяка държава има и глупави, и умни хора, важни са вторите. И с опит, и без опит. Но ако някъде има повече умни, на мен по-ми-харесва там. Така че – посланието на @Васил ми се струва даже в полза на Ruby нещото.
Аз даже си имам друг фаворит, ама няма да кажа кой, че там сме само от умните :).
July 3rd, 2015 at 15:19
Чета, мисля … после пак чета, пак мисля … и се чудя да сипя ли и аз и колко да сипя …
[Troll]
… докато ползвате езици за програмиране, който имат цифричка след името, ще страдате. Ултимативен bullshit е да има versioning зависимости в core language функционалност. Това говори за липса на maturity и липса на първоначален дизайн. На PHP му трябваха 5 major версии да стигне до идеята за ООП. Python е създаден, да предостави shell-like интерфейс към Amoeba … Ruby … ‘щото Matsumoto имал нужда от интелектуална маструбация … предполагам …
[Малко по-сериозно]
В общи линии съм съгласен с тезата на @Васил, че и PHP, и Ruby (и Lua, и Python до известна степен) са играчки.
Тези езици се създават през ’90-те, повлияни са силно от масовизацията достъп до компютри и Интернет. Първоначално зад тях не е поставен сериозен design и са рефлекция на вижданията на “автора” за това как трябва да се случват нещата. Развитието е органично и large-scale computing не е цел на никой от тях. Общностите компенсират deficiencies на език / библиотеки, но и създава условия за допълнителна фрагментация (версии, други/нови/несвойствени парадигми, справка: node.js vs. io.js).
Липсата на само-идентификация на езика с даден domain се вижда в залитане по разни парадигми (с / без OOP, с / без generics, etc). Често, това води и до липса на обратна съвместимост (Python 3 vs. Python 2).
Комуналната разработка (от community) води до създаване на тонове “works for me” решения. За сравнение искам да препоръчам книгата The C++ Standard Template Library (http://www.amazon.com/C-Standard-Template-Library/dp/0134376331/ref=la_B001KDNNOG_1_3?s=books&ie=UTF8&qid=1435927929&sr=1-3) на Александър Степанов, която представя различните design decisions, през които минават първоначални разработки на STL, кои са били основните design принципи, какви компромиси са направени, къде и защо. Някой може ли да ми посочи подобно нещо за PHP?
Допълнителни недостатъци, които аз откривам (за мен лично) в тази група езици е липсата на сериозни средства, който да подпомага процеса на разработка. И не, нямам предвид IDE-та и frameworks. Липсват сериозни debuggers, profilers, static source code analysis средства. Личен пример: първата стъпка в относително сложен CI/CD процес, който управлявам е static source code analysis. Ако има открити проблеми на този етап, build-ът се прекратява и връща. https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis … сранете само визуално бройката на C/C++ или Java с произволен от останалите.
Deployment техники … ех, само ако можеше python-pip да не слага build-essential по production сървъри … и НЕ! Docker е work-around, не е решение!
TL;DR
Защо PHP / Ruby / Python / Lua според мен са “играчки”?
– Защото им липсва (domain-)идентичност. (Сравни с ADA, C/C++, Java, Lisp, .NET)
– Защото нямат консистентен дизайн. (Сравни с ADA, C, Fortran, Lisp, Pascal)
– Защото нямат развита екосистема от средства за подпомагане ефективността на програмирането. (Сравни с ADA, C/C++, .NET)
– Защото в същината си deployment на код на тези езици e комплексен и error-prone процес. (Сравни с JAVA, .NET)
Disclaimer: аз пиша ежедневно на C/Bash/Python.