Scala в реальных проектах
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Scala выпиливается усиленными темпами из всех продакшнов. Это мертвый язык, на который не стоит тратить ни секунды времени.
— Знаете, почему у LinkedIn много лет такой тормозной, глючный и неудобный сайт? Потому что они надолго увязли в Scala и до сих пор не могут оправиться — www.quora.com/...
— Twitter отказывается от Scala — www.quora.com/...
— movio.co/...
— jimplush.com/...
— uberblo.gs/...
Привет Саша. Ты предлагаешь использовать гоу? А на сколько он зрелый в плане фрейворков различных под веб? В проде не страшно ранить?
А на сколько он зрелый в плане фрейворков различных под веб?Фреймворков под веб на go полно, но я с ними не работал — пока было достаточно стандартной библиотеки. Думаю, среди них найдутся несколько достойных.
В проде не страшно ранить?Страшно, но оно работает :) Причем перед сервисами на go нет никаких nginx’ов с apache’ами и haproxy — сервисы обрабатывают http и https запросы напрямую из интернета. Сейчас через них проходит 2 миллиона запросов в секунду от 8 миллионов одновременных подключений. Пока серьезных проблем не возникало.
Готовлюсь к выходу go 1.8 — github.com/...
Ждем адептов scala на нашем шабаше 25 февраля в Одессе vmes.vertamedia.com .
Правда, до сих пор нет generic’ов, монад, pattern matching’а, type traits, implicit’ов, inheritance и exception’ов.то есть до сих пор нет того, без чего современный язык — просто паскаль со скобочками?))
то есть до сих пор нет того, без чего современный язык — просто паскаль со скобочками?
github с вами не согласен насчет того, какой язык современнее:
— Scala — 60 популярных репозиториев
— Go — 378 популярных репозиториев
И с каждым днем разрыв между Go и Scala растет семимильными шагами — достаточно проверить эти ссылки через пару месяцев.
но т.к. нормального профайлера нет и пока не предвидится — то и использовать его в проде стремноЧто вы имеете ввиду под «нормальным профайлером»?
Профилировщик в go встроен в runtime и может собирать профили в любой момент прямо в продакшн, никак не влияя на производительность программы. Профилирование по CPU, памяти и блокировкам поддерживается из коробки — https://blog.golang.org/profiling-go-programs .
между Go и Scalaскала тут причем
Что вы имеете ввиду под «нормальным профайлером»?нормальный профайлер в первую очередь подразумевает наличие некой качественной ide
а) таковой нет
б) удобство просмотра результатов и сравнение результатов несольких сессий (только не надо мне говорить щито это делается парочкой грепов по текстовым файлам)
в) очень прикольно, когда срабатывает принцип Гейзенберга — профалер требует модификации наблюдаемой сущности)))
по итогу — нишевый инструмент без намека на универсальность
за последние годы ничего не изменилось
особенно прикольно будет посмотреть на лица гоферов, когда гуглята закроют лавочку
а они это делают крайне часто, особенно в последнее время))
Понятно. Для вас нормальный профайлер — это тот что с красивым gui и рюшечками. Для нас — тот, что помогает эффективно выявлять узкие места в продакшн под реальной нагрузкой, не снижая производительность программы.
вообще-то нормальный профайлер делать и то и другое (собственно профайлинг и вменяемая визуализация)
вам же приходится обходиться в лучшем половиной возможностей
ну что ж — дело армянских комсомольцев живет и поныне))
Извините, но чесно говоря, вы уже подзадолбали. Евангелизм это явно не ваше.
Если до того времени как я увидел, ваши посты, у меня было желание посмотреть в сторону го, то сейчас этот язык вызывает только одно отвращение, благодаря вашим стараниям и хайпа в интернете.
— Вам не казалось что мерят популярность языка, первая версия которого вышла в 2003 году, по количеству написаних библиотек, довольно тупо. Так как большинство уже давно написано, и развивается. В отличии от го, где экосистема еще только растет + да и не стоит умалчивать про проблемы с пакетными менеджерами.
— Замеры в интернете, который показывают пинг-понг между горутинами и особенно хайп вокруг gc, просто уже задолбал. Вам не кажется что те цифры что вы называете, в продакшене будут немного поумеренней, из-за наличия все таки полезной работы. А чудо-gc, вызывает только одну улыбку, да бы любой человек понимающий немного о gc, знаем что ничего не дается бесплатно, если есть перевес в сторону коротких задержек, значит будет ограничение в пропускной способностью
— Ссылки которые вы скинули с quora, вы их вообще открывали ? Linkedin успешно держить нагрузку на scala, при этом один из инструментов kafka вообще уникальный среди всех существующий брокеров, и он написан на scala.
Вам не приходило в голову, что для каждой задачи свой инструмент. Да ограничений и привязка, только к одному языку, в эпоху микросервисов, это довольно узколобо.
Извините если слишком агресивно, но было бы здорово если бы пересмотрели свои взгляды на продвижение go на dou.
Варианты:
— создать топик «Новости Go»
— еженедельный или месячный дайджест про Go
Картиночки для вброса:
pbs.twimg.com/...
pbs.twimg.com/...
у меня уже несколько раз было ощущение, что этот хлопец на самом деле ненавидит го, потому и пропагандирует его так, что вызывает обратный эффект
может его заставляют?))
этот хлопец на самом деле ненавидит го, потому и пропагандирует его такот любви до ненависти один шаг © =))
— Вам не казалось что мерят популярность языка, первая версия которого вышла в 2003 году, по количеству написаних библиотек, довольно тупо. Так как большинство уже давно написано, и развивается.java, php, python и javascript появились раньше scala, но это не сказывается на росте количества популярных репозиториев на github.
Вам не кажется что те цифры что вы называете, в продакшене будут немного поумеренней, из-за наличия все таки полезной работы.У нас в продакшне один физический сервер обрабатывает 200к http запросов в секунду от миллиона одновременных http keep-alive подключений в штатном режиме и достигает 300к запросов в секунду в пиках. Полезная работа — валидация входящих запросов, сбор и параллельная отправка статистики в несколько различных сервисов для последующей обработки/хранения.
А чудо-gc, вызывает только одну улыбку, да бы любой человек понимающий немного о gc, знаем что ничего не дается бесплатно, если есть перевес в сторону коротких задержек, значит будет ограничение в пропускной способностью1. Короткие задержки намного важнее пропускной способности.
Linkedin успешно держить нагрузку на scalaПроизводительность — не самое важное в коммерческой разработке (хотя доже на этом поле go уделывает scala’у как ребенка). Намного важнее readability, extensibility и maintainability кода. Вот с этим у LinkedIn явные проблемы. Скорее всего, scala сыграла в этом не последнюю роль. Иначе зачем они решили не использовать scala для нового кода и перевести все проекты на scala в режим maintenance?
при этом один из инструментов kafka вообще уникальный среди всех существующий брокеров, и он написан на scala.Что в kafka такого уникального?
Вам не приходило в голову, что для каждой задачи свой инструмент. Да ограничений и привязка, только к одному языку, в эпоху микросервисов, это довольно узколобоСогласен, что для каждой задачи есть наиболее подходящий язык программирования. Даже scala годится для каких-нибудь теоретических матановых задач. Но использовать scala в продакшн — это мазохизм для программистов и самоубийство для компании.
У нас в продакшне один физический сервер обрабатывает 200к http запросовОт никогда не понимал людей которые пишут подобные высеры.
Сервер
Запросы — различные события, связанные с показом рекламы. По каждому событию собирается до 40 различных параметров. Собранные данные отправляются в различные сервисы для последующей обработки, хранения и использования.
на нашем шабаше 25 февраля в Одессехех) вот я подумал — может таки пойти... знать бы только бесплатный шабаш будет или не, и какие именно мастер-клавссы там будут.
Вход бесплатный. Это go 1.8 release party, так что планирую рассказывать только про новые фичи этой версии.
Чем больше вижу подобных блог постов, тем больше убеждаюсь, что в нынышем «высоком айти» много безмозглых кретинов (без относительно спора о конкретных фич языков).
Согласен — зачем выбирать вначале scala, если затем ее не можешь асилить?
Какая то фигня, по поводу того, что твиттер собирается отказаться от скала. С того же гитхаба: 40 репозиториев на скале против одгно на го. И то, по ощущению попробовали один проект
Линкедин как юзал jvm стэк, так и будет в ближайшее время (5 и более лет) его юзать. А на ГО (вно ???) как то особо никто не собирается переходить.
Про ынтерпрайзы я вообще молчу, там никому даже в мыслях не приходит перейти с .net/jvm на го или еще на какую-либо экзотику.
А высказывания со всяких там квор и т.п. — с таким же успехом могли бы ссылаться на свои посты с доу.
Какая то фигня, по поводу того, что твиттер собирается отказаться от скала.Твиттеру тяжело отказываться от scala, т.к. в этой компании работает половина всех практикующих scala-программистов в мире. Они сильно вляпались в scala. Но им придется пройти очищение, т.к. даже VP of Platform Engineering в Twitter, Raffi Krikorian, позволил себе сказать такое о своем печально известном решении перевести Twitter на Scala:
What I would have done differently four years ago is use Java and not used Scala as part of this rewrite
Линкедин как юзал jvm стэк, так и будет в ближайшее время (5 и более лет) его юзать.jvm стэк это не только scala, от которой они отказываются в пользу plain old java.
Про ынтерпрайзы я вообще молчу, там никому даже в мыслях не приходит перейти с .net/jvm на го или еще на какую-либо экзотику.Go, в отличие от scala, подходит для кровавого ынтырпрайза по некоторым критериям:
— низкий порог входа
— масштабируемость на команды из тысяч программистов
К сожалению, Go не подходит по главному критерию ынтырпрайза — возможность неограниченного распила бюджетов с помощью многоуровневого наследования абстрактных фабрик визиторов синглтонов и senior solution архитекторов/консультантов.
То же можно сказать и про Гугл, которая не откажется от Go по естественным причинам, также как и Майкрософт не откажется от виндовс (хотя половина её сотрудников мечтают перейти на линукс:)))
Go используется в чуть более, чем 9000 компаний. Так что, если в руководство Гугл просочится Go-хейтер и уволит всю команду разработчиков Go во главе с Пайком, Фицпатриком и Коксом, то их быстро приютят компании типа Cloudflare, и спокойно продолжат развитие Go.
Так ГО уже ж «развили» почти до конца — скоро в нем появяться generics и check/handle(try ... catch). чем не c++ теперь
check/handle уже есть — blog.golang.org/defer-panic-and-recover
Дженерики не нужны. В следующей версии го появятся намного более крутые вещи:
1. #20706 General Unicode identifiers based on Unicode TR31: This addresses an important issue for Go programmers using non-Western alphabets and should have little if any impact on anyone else. There are normalization questions which we need to answer and where community feedback will be important, but after that the implementation path is well understood. Note that identifier export rules will not be affected by this.2. #19308, #28493 Binary integer literals and support for_ in number literals: These are relatively minor changes that seem hugely popular among many programmers. They may not quite reach the threshold of solving an „important issue” (hexadecimal numbers have worked well so far) but they bring Go up to par with most other languages in this respect and relieve a pain point for some programmers. They have minimal impact on others who don’t care about binary integer literals or number formatting, and the implementation is well understood.
3. #19113 Permit signed integers as shift counts: An estimated 38% of all non-constant shifts require an (artificial) uint conversion (see the issue for a more detailed break-down). This proposal will clean up a lot of code, get shift expressions better in sync with index expressions and the built-in functions cap and len. It will mostly have a positive impact on code. The implementation is well understood.
Дженерики не нужны.
Да, я вот тоже так считаю, но Роб Пайк похоже не согласен с нами. И решил добавить в язык и generic и exception handling по аналогии с try catch
go.googlesource.com/...master/design/go2draft.md
Вообщем ждем скорого падения популярности языка.
handle/check существенно упростит обработку ошибок, если примут этот драфт
go.googlesource.com/...rror-handling-overview.md
Можно будет избавиться от многочисленных проверок типа if err != nil { ... } с одинаковым кодом на случай ошибки, и при этом механизм обработки ошибок останется прежним. В общем, предложения очень толковые.
Драфт ухудшает читабельность кода. Появляется неявная передача err с неясным потоком исполнения. Уж лучше оставить явный, но немного многословный
if err != nil {...}
. Те, кто не любит его, могут эмулировать магию из этого драфта с помощью сомнительного кода:
func sum() (int, error) { // magic shit for `if err != nil { ... }` haters defer func() { if err := recover(); err != nil { return 0, err } }() check := func(err error) { if err != nil { panic(err) } } // actual code x, err := foo() check(err) y, err := bar() check(err) return x+y, nil }
Ничего не ухудшает, код вполне очевиден. К тому же вышеприведённый пример можно упростить по стандарту Go 2, что не выйдет с помощью этой «эмуляции»:
func sum() (s int, err error) { // actual code return check foo() + check bar(), nil }
-
По количеству вакансий на hh.ru Golang — 361, Scala — 455. И там и там мало, но у go меньше. Так что пока не вижу смысла на go переходить.
У нас на Scala ивент система, все таки Актеры прекрасно для этого подходят (можно скейлить по нагрузке).
Еще есть небольшой проект для домашнего Hadoop мониторинга на Play с Scala.
С следующего спринта будем мучать Spark с Scala (интересный уровень абстракции они предоставляют, надо пробовать :) ) в дополнению к уже существующему Hadoop с Java.
Так же где то ниже писали что не могут найти людей под Play — лично знаю человека который полтора года сидит на плейном проекте в Киеве.
ИМХО любой функциональный язык хорош для души программиста. Советую попробовать функциональную парадигму, не понравится, можно вернутся в итеративное программирование :)
Из реальных больших проектов что знаю: у Netflix весь видео стрим на скале; у twitter, foursquare и coursera — бекенд.
Язык развивается Typesafe фигачит и Akka фигачит :)
блин только заметил что это пост из 2012го. Кто ж его апнул 0_о
месяца полтора на качественный самостоятельный въезд в темудля качественного самостоятельного везда года 1,5 потребуется
А есть ли люди реально работавшие с Play? Мы начали искать программистов с реальным Scala опытом и похоже их на Украине почти нет :) А если еще в требования добавить Play так пока вообще 0 :) Я начинаю опасаться что рынок Скала программистов на Украине пока не сформировался. Надеюсь что это изменится.
Плей с полноценной поддержкой скалы вышел 4 месяца назад, до этого скала подключалась к плею костылем, поэтому ваша ситуация не удивительна
Не 0: у меня сейчас второй проект на play и предыдущий play — проект сейчас подхватился, уже наверное можно сказать, что нормально. Learning curve в play гораздо лучше чем lift, так что думаю можно просто искать тех кто работал с чем-то rails-подобным,
Людей пока мало, да.
ну так заказчика тоже нужно воспитывать. Такая спешка она везде будет.
А вы пробовали искать человека с джава опытом, но интересующегося скалой? Или вам только
Так происходит, Вадим, из за некоторой косности украинских компаний. Надо чтоб по новейшему фреймворку который вышел вчера было 5 лет опыта, как минимум. А если человек ещё и сам осваивал язык, то увы — всё печально.
Надеюсь что возьмусь за скалу через пару лет вместе с прошариванием функционального программирования как такового.
То есть .. никогда :)
www.coursera.org/...course/reactive
Уже можно записаться. Начнется в ноябре
Записался уже давно :) в скайп конфе по скала курсу уже давно проанонсировали
В тему Scala:
18 сентября на Coursera стартует курс Functional Programming Principles in Scala.
www.coursera.org/course/progfun
P.S. речь о Москве.
Ну можно просто начать отдельные части присать на scala — оно будет с работать out-of-the box. Для веба поверх сервлетов можно scalatrа прикрутить
Смотря для чего. Чтобы повысить з.п. явно не стоит, лучше спринг, хибернейт, вебсервисы и тонкости настройки баз данных. Короче троублшутинг. Скорее наоборот, если в проекте будет скала тебе будут пытаться продать вакансию как опупенно интересную и захотят платить меньше рыночной з.п(интересно же)
Для расширения кругозора стоит однозначно
Кстати, в последнем опросе зарплат можно выбрать scala как технологию и посмотреть что там с зарплатами.
Посмотрел. Аж три анкеты получилось: у одного товарища 2500, у другого 3300, у третьего 3500. Не сказал бы, что много за знание явно фриковского языка
-
Я думаю, на текущий момент это все относится к ненавистной тобой теме об «интерестных технологиях». Если будут платить хотябы так же как за жабу — то будет уже не плохо.
Если будут платить хотябы так же как за жабу — то будет уже не плохо
Не плохо чем? Какая разница на чём писать?
Зачем предпринимателю платить больше за скалу ?
Зачем тебе тратить время на изучение скалы, если за нее не будут платить больше?
Для расширения кругозора, см. выше
Зачем предпринимателю платить больше за скалу ?
Инструмент хорошо подходит для решения определённых задач, людей знающих этот инструмент мало. Хочу профит от правильного применения инструмента -> ищу людей его знающих -> людей мало -> плачу больше, чтоб найти.
Правда, как я уже говорил, пытаются компенсировать бОльшую сумму з.п. сказочками о интересных проектах.
Для расширения кругозора, см. выше
Расширять кругозор это одно, а нормально учить все тонкости яп — это другое.
Инструмент хорошо подходит для решения определённых задач, людей знающих этот инструмент мало. Хочу профит от правильного применения инструмента -> ищу людей его знающих -> людей мало -> плачу больше, чтоб найти.
Каких задач ? примеры ?
Каких задач ? примеры ?
Наверно таких:
ищу людей его знающих -> людей мало -> плачу больше, чтоб найти.
Зачем предпринимателю платить больше за скалу ?
А он платит не за скалу, а за результат. Если со скалой результат будет лучше, то и платить надо больше.
ИМХО, нет (по скорости написания не категоричне нет).Вот тут интересней всего, будет ли результат со скалой реально лучше? Хотя бы по простому критерию — скорость написания кода. затем устойчивость кода, расширяемость и удобство сопровождения.
Но есть люди которые считают что да. Видел успешное применение на небольших проектах в которых нет сверхактивного изменения бизнес-логики.
Опять же таки — примеры. Ибо, изходя из недостатков перечесленных мною же ниже — результат для нормальных проэктов будет хуже :-)
Ибо, изходя из недостатков перечесленных мною же ниже — результат для нормальных проэктов будет хуже
Ну я тебе уже намекал что большая часть твоих недостатков высосана из пальца.
А вот и нифига, за результат платят сдельщикам: сделай работу — получишь оговоренную сумму. В этом случае я уже партнёр и цена на мою работу возрастает многократно.
у нас в Мюнхене пишут на нем, есть проекты. Так что от рынка зависит и области применения
Стоит. В реальных проектах применяется и довольно активно. Навскидку — scala проекты в Украине наблюдались в strikead, gradsoft, daxx, adstream, skelia, luxsoft, и, кажется, кусочком в global-е. Это только из тех кто светился. Детали можно спросить в google group scala-ua (и вобще community: scala-lang.org.ua, www.facebook.com/...56373621041781 )
сейчас основная активность в FB группе:www.facebook.com/...roups/scala.ua
С сайтом — его делал @folone сто лет назад, при этом используя сайт-генератор на haskell-е, как он уехал из Украины так сайт и перестал обновляться. Сесть и разобраться что там и переделать ни у кого руки не доходят (хотя раз вспомнили — может быстрее дойдут)
Ну, Пейсбуком я не пользуюсь, потому что heshilao.livejournal.com/205681.html .
сто лет назад, при этом используя сайт-генератор на haskell-е, как он уехал из Украины так сайт и перестал обновляться.Кстати, типичная судьба проектов на скале, хаскеле, и т.п.
Это довольно таки другой стек. Например спринговые конфигурации ИМХО запросто покрываются implicit объявлениями. Для MVC — в скале свои фреймворки и т.п.
То есть я к тому что — не всегда стоит нести свои привычки в новое окружение.
Плей 2 наоборот задумывался как суперпроизводительный фреймворк, но особых подтверждений этому пока что не сильно видно на горизонте.
Скалу можно прекрассно юзать как better java для начала, выведение типов, лямбды, хорошо спроектированая библиотека колекций и некоторые другие батарейки сделают код намного чище.
То есть они могут алгоритм обработки данных построить в виде функций с функциональными конструкциями. Я честно сказать в аутсорсе мало видел таких ребят:) Есть конечно, но там где я работал их было мало. По своему опыту, мне доводилось видеть код написанный императивно, просто в виде алгоритма, некоего конечного автомата на джава, и код в функциональном стиле, написанный с помощью Google Guava.
Кстати подумалось что это все еще зависит от вида задачи, если задача связана с манипуляцией всякими коллекшнами, фильтрацией, агрегацией и т.д. коллекций, то да, функциональный подход рулит, если там какие то другие алгоритмы, или вообще бизнес логика для yet another crm/erp/ecomerce то выигрыш уже не так заметен, а то и превращается в проигрыш
Отзывы противоречивы. С одной стороны черезчур академично. С другой взят на вооружение некоторыми consultancy как competitive advantage. Вполне может и не взлететь как мейнстрим. Зубрить прямо сейчас может и не стоит, но если легко дается — покопаться не повредит. Поработать точно тоже.
AdStream постил здесь вакансии для какого то проекта на скала. Правда у них судя по всему там адский салат из bleeding edge технологий: mongodb, node.js, lift, scala опять же, я бы с опаской с таким салатом работать бы согласился.
Not that we needed all that for the trip, but once you get locked into a serious drug collection, the tendency is to push it as far as you can.
― Hunter S. Thompson, Fear and Loathing in Las Vegas: A Savage Journey to the Heart of the American Dream
я бы с опаской с таким салатом работать бы согласился.
а я бы — без.
Ну не все еще доросли до осознания ответственности за результат работы.
то есть один язык, один сервер приложений, одна БД — to rule them all — это и есть признак зрелости?
Проблема не в одном или двух языках, проблема в том что товарищи экстремалы взяли все самое сырое что есть на рынке.
mongodb сырое? scala & node.js тоже не очень новички и имеют сложившуюся репутацию.
По сравнению с mysql, posgres, ms sql server еще далеко не венец rock solid технологий. Тоже самое про скала, node.js(известен хоть один сакт на нем?) уж не говоря про лифт.
между rock solid и raw есть достаточно много еще этапов. Что есть сакт?
ох йо как то это черезчур неконсервативно. Чисто на резюме поработать — на месте владельца проекта мне бы было страшно
ну если люди знают что делают, то у них наверное будет большой competitive advantage. А если нет — то и более консервативный подход может не помочь.
угу, наверно. Я такие вещи пока готовить не умею от сюда и осторожность.
Ну вобще-то mongodb это по распостранению аналог mysql сегодня. То есть mongodb/Lift (сейчас ближе к mongodb/play) — это что-то вроде LAMP-а.
у вобще-то mongodb это по распостранению аналог mysql сегодняИнтересно откуда ты такое взял. www.indeed.com/...ysql,mongodb&l=
как всегда, у каждого такой свой мирок, который экстраполируют на всех остальных.
Мой хороший знакомый работает с этим языком, могу дать скайп в личку, если надо.
Хоть язык и интересный, но из того что писал Поллак, и другие умные дяди — скал а очень далека от реального использования.
Прикол даже не в сложности как таковой.
Вот вам короткий наброс почему я бы не выбрал скала для «нормального проэкту»:
-Несовместимость разных версий на уровне языка и компилятора.
-Несовместимость библиотек откомпилированных разными версиями языка.
-Поколения различных коллекций несовместимых друг с другом.
-Поддержка дслизации из коробки, когда есть варианты как синтаксически по разному написать один и тотже код.
-Интрисикты (или как там они прально называются).
-Мозговыносящая система типов.
-Комбинация из предедущих
-Очень длинный и неровный лернинг курв.
Это ты всего в интернетах начитался, если бы попробовал, понял бы что вышеописанное проблемами не является
я то какраз пробывал. Для небольших прожектиков написанных самому, для себя — действительно это все во многом не проблема. При бОльших проэктах с командами, думаю, это все будет проблемою, если и не сразу то потом. Хотя норот вон нодежс пилит и в ус не дует.
реальных проектов — это типа встроенная поддержка xml в языке? использование streaming xml parser? xml bindings?
-Несовместимость разных версий на уровне языка и компилятора.Раньше не обращал внимания
-Несовместимость библиотек откомпилированных разными версиями языка.
А вот это уже очень не смешно
-Поколения различных коллекций несовместимых друг с другом.
А пример можно?
-Поддержка дслизации из коробки, когда есть варианты как синтаксически по разному написать один и тотже код.
-Интрисикты (или как там они прально называются).
<.blockquote>
?????-Мозговыносящая система типов.Ну как бы когда в коде куча +T -T <: => и регулярки ну наверняка не читабельно
-Комбинация из предедущих4-х пунтков — читать уже написанный код местами тяжело. Очень тяжело читать быдлокод.
-Очень длинный и неровный лернинг курв.
128 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів