это динамический язык с простым синтаксисом и простой семантикой
Ну, давайте сравним c Ruby и PHP. Все 3 с динамической типизацией.
У Ruby наиболее читаемый синтаксис. У PHP - C-подобный синтаксис, который многим знаком с универа. У Python - самый непривычный синтаксис, чувствительный к уровню отступов.
По семантике самый простой Ruby - есть только объекты и методы. В PHP и Python у вас есть ещё и процедуры, что повышает когнитивную нагрузку, напр. len(str), а не типичный для ООП str.length
При этом он ещё имеет огромный репозиторий готовых библиотек.
Это следствие популярности, а не причина. Вы ставите телегу впереди лошади.
Думаю, имеется в виду, что во многих ФП языках нет такого понятия как массив, есть только связный список. Да и в целом все данные неизменяемые, поэтому легко придумать синтетический тест, который будет постоянно что-то менять in-place в массивах, классическая Game of Life например, и ФП-реализация очевидно проиграет по производительности.
ФП обычно идёт неразрывно с неизменяемыми структурами данных. Это уменьшало производительность программ, актуальных в 80-90 годах. Сейчас уже разница в производительности не особо велика в подавляющем большинстве случаев, т.к. компиляторы уже научились многое оптимизировать. Зато ФП сильно повышает надёжность программ.
Ну, если вы хотите жить в мире, где подмена понятий в норме вещей, то может и не важно. Однако есть только одно официальное определение ООП - от Алана Кея. Всё остальное - это фантазии людей, которые захотели хайпануть и напридумывали извращенных трактовок.
Мне кажется, за последние 50 лет термины уже должны были устояться ;) Я бы предложил полистать книжку: Гради Буч, Объектно-ориентированный анализ и проектирование с примерами приложений.
А я вот до сих пор офигеваю от того, как легко провели тут подмену понятий, при том, что все материалы есть, с автором концепции ООП можно было свободно пообщаться и т.д.
Знаете игру "Испорченный телефон", где люди передают друг другу информацию по цепочке? Вот Гради Буч в этой игре - тот самый человек, который и сам ничего не понял, и после него вся остальная цепочка идёт по п*зде.
Уже сотни статей написаны на тему того, что наследование, инкапсуляция и полиморфизм ни малейшего отношения к ООП не имеют, и вообще абсолютно ортогональны парадигмам программирования. Но до сих пор находятся люди, которые в детстве книжку Буча почитали и с тех пор больше в этот вопрос не углублялись.
А теперь подумайте, почему сейчас Питон (как фронтенд к оптимизированному беку) - король горы во всяких научных вычислениях
Исключительно потому, что Google ему профинансировала мощную маркетинговую кампанию и поддержку в целом в конце нулевых. Тот же Ruby гораздо более ООП, чем Python. Ни одной объективной технической причины в популярности Python вы не найдёте. Одни следствия того, что кому-то в Google он субъективно понравился или как-то иначе договорились.
Вы правда собираетесь КАЖДОЙ функции передавать в качестве аргументов инстанс коннэкшна к БД?
Хоть я не автор, но отвечу. Особенность реализаций того, что сейчас принято называть ООП, в том, что по сути именно это и происходит - КАЖДОМУ методу просто в неявном виде передаётся инстанс объекта в качестве нулевого аргумента.
Чем лучше заменить вызов функций через точку и скобки для аргументов предлагаю обсудить в комментариях
pipe-оператором, чем же ещё...
Позволяет передавать данные от функции к функции, и концептуально хорошо знаком всем, кто работает в консоли. Elixir и F# передают привет всем, кто ещё не додумался
IBM и компании, которые используют на IBM i, не особо то заинтересованы в популяризации этой платформы. Попытки портировать более распространенные языки на эту платформу были, но кажется большинство устраивает RPG и Cobol
Строго говоря, С и С++ тоже расходятся в разные стороны все дальше и дальше...
Соглашусь. Я имел в виду, что у этой парочки хотя бы есть совместимость на уровне того, что компилятор C++ понимает и код на C. Во всяком случае, так было, когда я прошлый раз этим интересовался.
Вот все не могу взять в толк - backend разработка - это вообще что? То, что крутится на сервере безо всяких интерфейсов, в фоне?
Ну, интерфейс должен быть, просто программный - в виде API, которое в свою очередь дергает frontend, инициируя тем самым HTTP-запросы. То, что крутится в фоне относится к фоновым задачам. Это можно рассматривать как часть backend-разработки, но не всегда. Например, там может, какая-нибудь ML-модель крутиться, или отдельный Data Lake. Поэтому иногда уточняют, что к backend относится только OLTP слой.
Это больше вопрос определений. Полнотой по Тьюрингу они обладают, пусть и с некоторыми оговорками (напр. взять не ANSI SQL 99, а TSQL), значит, при желании можно и языком программирования назвать. Но можно и менее спорные примеры нишевых ЯП привести: R, 1C, Q#
Что-то сомневаюсь, учитывая то, что это прям в вакансиях указано...
Читайте внимательнее, там в скобочках написано Логистика. Вот она на PHP, но к Самокату этот проект отношения не имеет, хоть и вошёл в холдинг.
На Saint Highload++ 2024 мне клятвенно заверяли на стенде, что есть PHP.
Ну, вас либо дезинформировали, либо вы неправильно поняли. Что, в целом, не мудрено. После слияния компаний в единый холдинг HR-бренд какое-то время назывался Samokat.tech, хотя по факту включал не только Самокат, но и Мегамаркет и Логистику. Это пофиксили переименованием бренда в Ecom.tech
Я так то руковожу одним из направлений разработки в Ecom.tech, к которому относятся и Самокат, и Мегамаркет, и Купер. Ни в одном из них нет PHP. Так что ошибаетесь тут только вы xD
Если уж вам так интересно про Самокат, то тут на бекенде исключительно Kotlin, Ruby и Elixir.
Насчёт Яндекс.Еды уточнил, действительно есть пока legacy на PHP, от которого они планируют избавиться в этом году. Основная разработка идёт на C++, Go и Python. Есть даже статья на Хабре, описывающая их страдания с этим PHP legacy: https://habr.com/ru/companies/yandex/articles/756498/
Вы бы хоть уточняли, куда завезли и как там у них с мутабельностью?
Не сходится, Ruby долгое время был популярнее Python. А PHP так был популярнее их обоих.
Ну, давайте сравним c Ruby и PHP. Все 3 с динамической типизацией.
У Ruby наиболее читаемый синтаксис. У PHP - C-подобный синтаксис, который многим знаком с универа. У Python - самый непривычный синтаксис, чувствительный к уровню отступов.
По семантике самый простой Ruby - есть только объекты и методы. В PHP и Python у вас есть ещё и процедуры, что повышает когнитивную нагрузку, напр.
len(str), а не типичный для ООПstr.lengthЭто следствие популярности, а не причина. Вы ставите телегу впереди лошади.
Не судите только про ФП по данной статье. Я даже не знаю, чем надо было думать, чтобы взять TypeScript и Go в качестве примеров функциональных языков.
Думаю, имеется в виду, что во многих ФП языках нет такого понятия как массив, есть только связный список. Да и в целом все данные неизменяемые, поэтому легко придумать синтетический тест, который будет постоянно что-то менять in-place в массивах, классическая Game of Life например, и ФП-реализация очевидно проиграет по производительности.
ФП обычно идёт неразрывно с неизменяемыми структурами данных. Это уменьшало производительность программ, актуальных в 80-90 годах. Сейчас уже разница в производительности не особо велика в подавляющем большинстве случаев, т.к. компиляторы уже научились многое оптимизировать. Зато ФП сильно повышает надёжность программ.
Ну, если вы хотите жить в мире, где подмена понятий в норме вещей, то может и не важно. Однако есть только одно официальное определение ООП - от Алана Кея.
Всё остальное - это фантазии людей, которые захотели хайпануть и напридумывали извращенных трактовок.
А я вот до сих пор офигеваю от того, как легко провели тут подмену понятий, при том, что все материалы есть, с автором концепции ООП можно было свободно пообщаться и т.д.
Знаете игру "Испорченный телефон", где люди передают друг другу информацию по цепочке? Вот Гради Буч в этой игре - тот самый человек, который и сам ничего не понял, и после него вся остальная цепочка идёт по п*зде.
Уже сотни статей написаны на тему того, что наследование, инкапсуляция и полиморфизм ни малейшего отношения к ООП не имеют, и вообще абсолютно ортогональны парадигмам программирования. Но до сих пор находятся люди, которые в детстве книжку Буча почитали и с тех пор больше в этот вопрос не углублялись.
Вы тут сами запутались. Для ФП принципиально важно, чтобы были first-class functions и HOF, без этого действительно получится ПП
Исключительно потому, что Google ему профинансировала мощную маркетинговую кампанию и поддержку в целом в конце нулевых. Тот же Ruby гораздо более ООП, чем Python. Ни одной объективной технической причины в популярности Python вы не найдёте. Одни следствия того, что кому-то в Google он субъективно понравился или как-то иначе договорились.
Хоть я не автор, но отвечу. Особенность реализаций того, что сейчас принято называть ООП, в том, что по сути именно это и происходит - КАЖДОМУ методу просто в неявном виде передаётся инстанс объекта в качестве нулевого аргумента.
Модель акторов гораздо лучше для проектирования систем подходит. И придумали лет 40 назад уж. Хотя в те времена - это и называлось ООП)
pipe-оператором, чем же ещё...
Позволяет передавать данные от функции к функции, и концептуально хорошо знаком всем, кто работает в консоли. Elixir и F# передают привет всем, кто ещё не додумался
IBM и компании, которые используют на IBM i, не особо то заинтересованы в популяризации этой платформы. Попытки портировать более распространенные языки на эту платформу были, но кажется большинство устраивает RPG и Cobol
Соглашусь. Я имел в виду, что у этой парочки хотя бы есть совместимость на уровне того, что компилятор C++ понимает и код на C. Во всяком случае, так было, когда я прошлый раз этим интересовался.
Ну, интерфейс должен быть, просто программный - в виде API, которое в свою очередь дергает frontend, инициируя тем самым HTTP-запросы. То, что крутится в фоне относится к фоновым задачам. Это можно рассматривать как часть backend-разработки, но не всегда. Например, там может, какая-нибудь ML-модель крутиться, или отдельный Data Lake. Поэтому иногда уточняют, что к backend относится только OLTP слой.
Это больше вопрос определений. Полнотой по Тьюрингу они обладают, пусть и с некоторыми оговорками (напр. взять не ANSI SQL 99, а TSQL), значит, при желании можно и языком программирования назвать. Но можно и менее спорные примеры нишевых ЯП привести: R, 1C, Q#
Читайте внимательнее, там в скобочках написано Логистика.
Вот она на PHP, но к Самокату этот проект отношения не имеет, хоть и вошёл в холдинг.
Ну, вас либо дезинформировали, либо вы неправильно поняли. Что, в целом, не мудрено. После слияния компаний в единый холдинг HR-бренд какое-то время назывался Samokat.tech, хотя по факту включал не только Самокат, но и Мегамаркет и Логистику. Это пофиксили переименованием бренда в Ecom.tech
Ох, ну вы меня насмешили, конечно 😂
Я так то руковожу одним из направлений разработки в Ecom.tech, к которому относятся и Самокат, и Мегамаркет, и Купер. Ни в одном из них нет PHP. Так что ошибаетесь тут только вы xD
Если уж вам так интересно про Самокат, то тут на бекенде исключительно Kotlin, Ruby и Elixir.
Насчёт Яндекс.Еды уточнил, действительно есть пока legacy на PHP, от которого они планируют избавиться в этом году. Основная разработка идёт на C++, Go и Python. Есть даже статья на Хабре, описывающая их страдания с этим PHP legacy: https://habr.com/ru/companies/yandex/articles/756498/
Ну, с этим можно согласиться. Важнее следить за своей областью. Хотя новостями из остальных время от времени интересоваться - тоже не грех.
А в чём проблема? Я в прошлом году нанимал Elixir разработчиков. Выбор вполне хороший и в итоге классных спецов подобрал.
Закиньте вакансию в tg-канал pro.elixir