LINUX.ORG.RU

Почему во многих Питон-проектах не используют async/await и ООП, как в Java?

 , , ,


2

1

Привет, всем. По работе смотрю новые питоновские проекты, и немного удивляет следующие детали:

  1. по сей день, пытаются все оформить сугубо через def() и форкать разные Py-скрипты через систему

  2. не смотря на наличие async/await в Python v3 - не используют и не пытаются

  3. если и объявят class , то он сугубо используется для DAO/DTO, ни каких сложных ОО-дизайнов не оформляется… type hints не испольуются, ABC-контракты не используются, GoF-паттерны тоже

  4. прикрываются якобы композицией, и что вообще ОО-дизайн - мертвый дизайн (у Golang лагеря насмотрелись, что ли?)

Говорю не про публичные проекты, которые в GitHub можно найти. А про многие, которые делает разработка в рос. компаниях. Картину наблюдаю на разных компаниях в течении последних двух лет.

Вот, я не пойму… Я что-то не понимаю или что? Вроде, появляются различные интересные фичи в Python3 , ряд вещей позволяет приблизится к написанию кода, как на Java.

Все-таки, Python не является Haskell, OCaml или каким-нибудь диалектом LISP. Это язык с элементами функциональщины, а не pure functional language, как Haskell. Так от чего не снабдить свой код asyncio, все граммотно оформить по ОО-дизайну с SOLID-принципами, четко разработь с event loop и прочим… Все какая-то портянка из 100500 глобальных def’ов вижу, в основном, в проектах. Да и вроде… Компании - солидные и платят этим Питонисам 250+ рублей в месяц. А стиль написания такой, за который могли бы уволить джуна в 2010ом, если речь шла про другой стэк (C#, Java).

Вопрос: от чего же в новых питоновских проектах на живой практике многие разработчики не пытаются применить фичи из последней версии языка, и приблизиться к дизайну/стилю кода, как на Java. И вообще, все сделать по канону чистенько, соблюдая SOLID. При наличии уже таких возможностей.

Это лень и нежелание просто? Или есть объективные причины забить болт на все это, и далее оформлять спагетти-код километровый?

P.S. не удтверждаю, что я - прав. Возможно, я совсем не прав. Я просто реально не понимаю, почему качество Питон-проектов, как было примерно таким 10 лет назад, то таким и осталось… Адепты на других языках, как-то более лучше развиваются в плане чистоты своих проектов. Опять сугубо моё ИМХО.

Ответ на: комментарий от small-entropy

Все верно написал. К Python есть множество вопросов касательно его текущего состояния и развития. У него нет конкурента, поэтому будем и дальше страдать, плакать, смеяться с него и всего того, что его окружает.

anonymous
()
Ответ на: комментарий от twinpeaks

не надо «ля-ля», есть, самый яркий пример - иди в трейдеры, FOREX всякие, есть такая тема как HFT (High-frequency trading), и никто там не пишет на Го или Жабе, все на С++ или plain C, как правило… и на это есть логическое объяснение

Ловите наркомана!

anonymous
()

Почему во многих Питон-проектах не используют async/await и ООП, как в Java?

Говорили Питонисты  бяки-буки,
Как выносит их земля?
Дайте им PHP что ли в руки
Погадать на Гвидуна.

Ой-ля-ля, Ой-ля-ля,
Погадать на Гвидуна,
Ой-ля-ля, Ой-ля-ля,
Ех-ха!
anonymous
()

Да там один хрен gil, это всё не на 100% серьёзно. А везде пхать ооп это рак.

anonymous
()
Ответ на: комментарий от twinpeaks

или plain C, как правило… и на это есть логическое объяснение

Да-да, вот в plain C напиши мне этот, как его, синглетон, пожалуйста. Чтобы всё было как в GoF. Иначе скажу, что плохой язык, однозначно.

Эк тебя кидает-то.

99.9999999% проектов не имеют ничего общего с форексом и HFT, и ничего не выиграют от используемых в них подходов.

Равняться на HFT, всё равно, что сказать, что жоповозка для поездок на работу должна делаться по технологиям, используемым в танке T-90.

Да и вообще, у тебя явная фиксация на ажиотажных технологиях (хайпе, так тебе наверное понятнее будет). Типа того, что есть серебрянная пуля: если взять такой-то язык, да такие-то паттерны, то любая задача по плечу:

— Мне нужен сайт для любителей котиков, где они смогу общаться и постить фоточки. Предполагаю, что в нашем городе найдется 200 любителей котиков, из которых 50 скорее всего будут активны на сайте.

— Тэкс, вам надо взять k8s, микросервисы, 30% микрос-в написать на Java, 30% на C#, 30% на С++, остальное на Haskell (хотя он не поддерживает паттерн синглетон, а потому говно, но сойдёт для второстепенных задач), в качестве БД нельзя обойтись без MongoDB, Greenplum, и Cassandra. Ещё понадобятся Kafka и RabbitMQ. Надо набрать команду из 350 специалистов по DAO, DTO, GoF, HSE, MSME, DTF, AESIP, RTP, EBG, итп.

emorozov
()
Ответ на: комментарий от emorozov

emorozov (08.12.21 09:54:54)

Да-да, вот в plain C напиши мне этот, как его, синглетон, пожалуйста. Чтобы всё было как в GoF. Иначе скажу, что плохой язык, однозначно.

Меня ни фига не кидает, ты из контекста вырвал - это раз. Так что, вырубай в себе «Ксению Собчак», твой подкол - ливерный, и вот почему:

  • я говорил сугубо в контексте high load
  • помимо plain C упомянул С++
  • при этом, сказал про нищу, что это связано с Forex/HFT
  • если ты имел опыт с всякими ECN и Metatrader, то должен знать, что там именно как раз все на С/С++ преимущественно
  • почему я должен отрицать, что под HFT пишут на plain C, если реально пишут модули на практике к всяким ECN-решениям?
  • причем тут GoF? конкретно в данном контексте

emorozov (08.12.21 09:54:54)

Равняться на HFT, всё равно, что сказать, что жоповозка для поездок на работу должна делаться по технологиям, используемым в танке T-90.

А у тебя, шалун, интересные фантазии :) Вместе с БДСМ-котятрой на БДСМ-форумах тушуетесь, исчете себе интересную пару, с кем можно плетки и тентакли?

emorozov (08.12.21 09:54:54)

(хайпе, так тебе наверное понятнее будет).

Лучше наполни свою экзистенциальную пустоту своим Питончиком.

emorozov (08.12.21 09:54:54)

Типа того, что есть серебрянная пуля

Ее - нет, никто не говорил, что существует сереберянная пуля. Суть трэда, что питонисты - о@%ели, пишут свои def() глобальные, ничего не хотят структурировать и т.д., уже обмусолили, а ряд питонистов в данном треде еще это подтвердило словами:

  • мы так делаем, ну и чо?

emorozov (08.12.21 09:54:54)

в качестве БД нельзя обойтись без MongoDB, Greenplum, и Cassandra.

Дед мороз, это тебя кидает не хило. Ну и на фига, ты упомянул Greenplum? OLAP-решение, которое сугубо подходит под опред. направление, связанной с BigData и аналитическими запросами? Лучше бы уж доупомянул OLTP-решение в виде Postgres, ибо с ним в основном рынок работает, включая ваших питонистиков-программистиков. Еще приставил сюда DAO, DTO? Причем тут это? Не удалось тебе поумничать дед мороз, не удалось.

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 1)
Ответ на: комментарий от emorozov

Я писал на PHP немного года где-то до 2007. В те года PHP был полным дном.

А в чём в 2007 он был хуже Python тогда? А чем современный PHP хуже современного Python? Давайте предметно тогда уж. «Дно» - понятие не сильно понятное.

Не сомневаюсь, что за прошедшее время он улучшился, но мне даже неинтересно изучать, что за улучшения там получились. Чтобы он перестал быть дном, он должен был стать совсем другим языком.

Внезапно, но PHP и стал совсем другим языком. Я бы сказал, что он стал ближе к Java, только шустрее.

Последний код на PHP, который я трогал, был галереей для фотографий (тогда не было инстаграмма, а были популярны различные галереи), продававшейся за десятки или сотни евро, в которой почти не было функций: любой повторяющийся код просто копировался Ctrl-C/Ctrl-V.

Говнокод можно сделать на любом языке. Я такое видел только в рамках API написанного на Python актуальной версии пару лет назад. И это что-то говорит о самом языке? Ну разве, что Python-сообщество больше придерживается KISS, а вот на DRY обычно клали и кладут (а в PHP по крайней мере говорят о DRY, но как сейчас - ХЗ, не работаю с ним уже почти 4 года).

Соответственно, любое исправление обязательно требовало поиска такого же куска кода во всех файлах галереи, и внесения однотипных исправлений.

Вопрос в лоб - а зачем галерею писать на PHP? Это вроде как задача фронта. или я чего-то не понимаю.

После этого я, как уже писал выше, навсегда зарёкся касаться PHP кода. Ни за какие коврижки.

Лучше не касаться кода рукожопых разработчиков. Язык тут на самом деле не причем.

И это был отнюдь не единичный случай. Почти весь код на PHP, который я когда-либо видел, был нечитаемой кое-как сляпанной лапшой.

Про Python могу сказать то же самое. Весь код, который я видел - не поддерживаемый комок грязи, решённые «влоб» задачи, без какого-либо признака понимания хоть какой-то парадигмы или паттернов.

Да и сам язык представлял из себя убожество.

В чем? Так и не пояснили не разу. Не защищаю PHP, но если сравнивать с Python - не вижу принципиальных недостатков, местами был хуже, местами - лучше. Но в целом - для веба языки как минимум равнозначные.

Единственным его преимуществом было то, что не надо было настраивать инфраструктуру: если для того же Python требовалось ещё знать что такое вебсервер, интерфейс взаимодействия между вебсервером и твоим кодом, то на PHP можно было начинать хреначить код сразу же после установки, не > читая и не узнавая ничего

Это достигалось постановкой какого-нибудь LAMP и не относится ни разу к языку, а просто набор технологий. Аналогичным образом можно собрать стек под любой язык и какой-нибудь AMPPS тоже не первый день существует. Про сразу херачить код - с Python не вижу разницы опять же. Так же ставишь, херачишь код.

Это приводило к феерическим провалам, и породило целую волну «разработчиков», программирующую методом сборки корабля в бутылке: трясти бутылку (изменять хаотично код), пока кораблик не соберётся.

Внезавно, такое же можно сказать про Perl, TCL и даже PureC (его так же можно использовать через CGI). Это как раз проблема среднего уровня квалификации по больнице. Тогда ситуация была репрезентативна для стека PHP, теперь PHP заменил Python. Вот и всё.

Помню эти портянки списков функций в PHP, в которых половина функций дублировала друг-друга, и все они не имели никакой системы в именовании.

Из практики. Писал далеко не джун на Python. Два мега-метода для API, которые представляли функцию длинной в 5к строк кода. Даже без комментраиев. Отличались они точечно изменённой логикой (не значительно, по итогу - строчек 100-150). Опять же - писал не PHP разработчик, а именно Python программист с опытом более пары лет.

Сейчас всё это может быть изменилось, но совершенно неинтересно проверять.

Поэтому вы погрузились в Python, где ситуация ничуть не лучше?

small-entropy
()
Ответ на: комментарий от twinpeaks

Ее - нет, никто не говорил, что существует сереберянная пуля. Суть трэда, что питонисты - о@%ели, пишут свои def() глобальные, ничего не хотят структурировать и т.д., уже обмусолили, а ряд питонистов в данном треде еще это подтвердило словами

Суть треда в том, что ты столкнулся с плохим кодом где-то. Плохой код, как пишет здесь каждый защитник своего языка, можно найти на любом языке.

В принципе, с этим согласен. Лично мне только кажется, например, что субъективно плохого кода больше на некоторых других языках, например, PHP. С другой стороны, это не представляется возможным оценить, т.к. понятие «плохого кода» сильно субъективно, поэтому объективные критерии оценки не выработать. Кроме того, оценить весь написанный код невозможно, например, код пропиетарных продуктов никто оценить не даст.

Лично я хорошего кода на Python видел больше, чем плохого. Сейчас качество кода на Python в среднем снижается, т.к. в Python (но и в IT вообще) стремятся пойти все кому не лень, из-за больших денег. Полагаю, что тот же процесс происходит и во всех других языках по той же причине. Возможно, с несколько отличающейся скоростью, т.к. со стройки в Python войти проще, чем в Java, тем более, С++.

Второе, что ты с самого начала утверждал, что хороший код — только тот, который удовлетворяет паре-тройке формальных признаков, основные - паттерны GoF и использование асинхронщины.

Про GoF я уже устал повторять, можно заново перечитать.

Про асинхронщину вообще претензий не понимаю. Я ещё не встречал человека, который бы в неё не смог въехать. Это не Rocket Science, и на нелюбимом тобой питоне можно свой event loop со своими корутинами запилить наверное в 100-150 строк за вечер легко. Просто для того, чтобы понять, как устроена асинхронщина под капотом, и что там не требуются глубокие эзотерические знания. Хотя на самом деле никто так не делает, и это не требуется.

Да и кроме того, что такое асинхронщина? Это приём программирования, применимый для очень узкого диапазона задач. Предположу даже, что если 70% async кода переписать в синхронной манере, никто не заметит разницы, ибо постоянно вижу асинхронщину затянутую только потому что модно.

emorozov
()
Последнее исправление: emorozov (всего исправлений: 2)
Ответ на: комментарий от tz4678

будто на похапэ или джаве что-то кроме делают (примеры с житбрейнсом не катят, так как и на питоне тот же саблим наполовину написан и есть всякие spyder ide)

А что по вашему не говносайт? Скажем тот же Facebook? Плюс - любой серьезный проект - это множество сервисов. Но по вашему комментарию я могу предположить, что «не говносайт» это приложухи, а не web. Тогда спешу расстроить. Ваш Python заборол JS на котором over9000 приложений для декстопа, мобилок и даже микроконтроллеров.

метапрограммированием он лучше

Чем его реализация лучше, чем в той же Ruby или Perl6/Raku. Не будем даже пока вспоминать про Lisp.

и своими ORM

ORM не часть языка, ещё раз. И про какую ORM вы говорите? Чем она хуже аналогичных на любом другом языке? Опять же, чтобы сравнивать хотя бы примерно - сравнение с ORM для NodeJS и Ruby. Давайте уж конкретики больше.

которые не были такими бы изящными без этого самого метапрограммирования.

Почти в любом современном стеке для enterprise есть язык, который позволяет писать DSL. Не вижу принципиально ничего в этом случае у Python лучше, чем на том же Ruby, Java. Если сравнивать с Lisp-family, Erlang, Rust, Haskell - так будет вообще избиение Python ссаными тряпками.

лучше стандартной библиотекой, которая структуирована в виде модулей, а не 100500 функций в глобальном неймспейсе.

Чем она лучше той же стандартной библиотеки Rust, Ruby, Haskell, etc.? Или давайте сравним со Smalltalk, на самом деле он эталонное воплощение для ООП языка. Чем Smalltalk/Pharo для примера хуже?

лучше явы тем, что не нужно городить на каждый чих класс.

Так и не надо говорить. Смысл ООП в осознанном выделение доменов/акторов и их аспектов.

small-entropy
()
Последнее исправление: small-entropy (всего исправлений: 2)
Ответ на: комментарий от small-entropy

Для тех кто в танке: оно позволяет писать вот так вот:

class User(db.Model):
    email = db.Column(db.String, unique=True)
    # перечисление полей
    class Meta:
        __tablename__ = 'users'


user = User(email='tz4678@gmail.com', password='123456')
user.save()

так изящно ты ни на чем не напишешь… у питона есть недостатки реальные, о которых тролота не упомянула даже типа рассово неверной области видимости и тп

var = 42
def foo():
  var = 'foo'
foo()
print(var)  # выведет не то чтобы хотелось

и это уже архитектурный изъян, который никак не исправить.

tz4678 ★★
()
Ответ на: комментарий от tz4678

и заметь: в питоне по-сути без ооп обойтись нельзя, когда другие пишут, что но не нужно, поразумевают JavaOOP™

tz4678 ★★
()
Ответ на: комментарий от tz4678

# выведет не то чтобы хотелось

Почему? В моей копии выводит именно то, что хотелось бы.

LamerOk ★★★★★
()
Последнее исправление: LamerOk (всего исправлений: 1)
Ответ на: комментарий от tz4678

tz4678 ★★ (08.12.21 13:31:25)

так изящно ты ни на чем не напишешь…

Офигеть, как «изящно»… Как понимаю:

  • exception handling писать при работе с СУБД не надо?
  • DbC (Design by Contract) для вход. аргументов, особенно для таких ЯПов, как Питон или Руби не надо?
  • вызов .save() синхронный?

Это, я к тому, что: «как бы твоя потрянка на Питоне выглядела бы, если все правила соблюдать при боевой коде?»

P.S. вообще хочецо покуражицо надо твоим кодом, с точки зрения логики если на стороне РСУБД я начну с MVCC играцо, аля:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ READ WRITE;

И глянуть, как ты параллельно работать будешь, если будут 2, 3 и др. клиенты, ну ладно :)

P.S. #2

По мне так, Haskell поизящнее будет, если мы сугубо только про «изяность» беседуем:

instance FromRow Present where
  fromRow = Present <$> field

instance ToRow Present where
  toRow p = [toField (presentName p)]

instance FromRow Child where
  fromRow = Child <$> field <*> liftM2 Location field field

instance ToRow Child where
  toRow c = [toField (childName c), toField (locLat (childLocation c)), toField (locLong (childLocation c))]


allChildren :: Connection -> IO [Child]
allChildren c = query_ c "SELECT name, loc_lat, loc_long FROM child"
twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 1)
Ответ на: комментарий от emorozov

emorozov (08.12.21 13:00:17)

Второе, что ты с самого начала утверждал, что хороший код — только тот, который удовлетворяет паре-тройке формальных признаков, основные - паттерны GoF и использование асинхронщины.

Где я удтверждал именно ровно в такой точно формулировке?

что хороший код — только тот

Я не давал ни каких оценок «хорошему» или «плохому» коду в целом. Я напомню, я говорил что:

  • питонисты ничего не соблюдают (про паттерны) в своей массе
  • не любят юзать async/await , хотя большинство языков обзавелось этим и многие юзают

К примеру, в той же Java - нет async/await (но есть в C#), но суть не в этом. Ты всё хочешь увести, что мол я якобы говорю:

Если нет паттернов, GoF, async/await - то это априори плохо.

Нет, я так не говорил. И это не плохо. Сразу тебе отвечаю. К примеру, я Haskell люблю мацать, ес-но там ОО-дизайн не всрался и типа async/await основан на Монадах может быть:

import Control.Concurrent.Async (async, wait)

newtype Task a = Task { fork :: IO (IO a) }

newTask :: IO a -> Task a
newTask io = Task $ do
    w <- async io
    return (wait w)

instance Monad Task where
    return a = Task $ return (return a)
    m >>= f  = newTask $ do
        aFut <- fork m
        a    <- aFut
        bFut <- fork (f a)
        bFut

Просто, это означает:

  • иной дизайн
  • иную парадигму
  • иные правилы

НО! Сцуко, правила-то все равно есть!!! Т.е. хочешь - не хочешь, но они есть, они просто иные. Поэтому, я не мог априори говорить, что GoF - это высечено на крови обязаловкой. Нет.

GoF и паттерны хорошо подходят для своей нищы: C#, Java, C++. Но! Поскольку, в Python v3 добавилось многое, что позволяет хоть «как-то» приблизиться и перестать писать говно из def()-глобалок, то почему бы Питонистам не перевоспитаться?

Плюс, соблюдение ОО-дизайна и GoF, там где это надо - хорошо, потому что обязывает структурировать, а не делать лапшу из 100500 глобальных функций.

P.S. и что есть адекватные питонисты, которые и в этом треде написали, что:

  • структурируют
  • даже какие-то паттерны применяют и др.

Я это признаю, НО! подчеркиваю, что таких - меньшинство. Речь в треде - о грехах большинства.

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 3)
Ответ на: комментарий от twinpeaks

sqlalchemy поддерживает async/await. все зависит от размера проекта, набора фич. под fastapi и пр aiohttp до сих пор нет нужных библиотек. ты упоминал тут graphql, которые решает множество проблем при проектирование api, так вот graphene с асинхронностью не дружит… но чат на веб-сокетах и пр уведомления в реальном времени нужны, но нам не нужно пытаться все сделать в рамках монолита - микросервисы. autocommit можно включить/отключить… че угодно делать. читай маны. design by contract - «не нужно». код на хацкеле - просто треш. на питоне нет ни одного популярного фреймворка с классическим mvc.

tz4678 ★★
()
Ответ на: комментарий от twinpeaks

GoF и паттерны хорошо подходят для своей нищы: C#, Java, C++.

Напиши хотя бы один говносайт на джанге, потом не си свою ересь. Вот напиши его с применением всех своих любимых паттернов, и посмотрим, что получится

tz4678 ★★
()
Ответ на: комментарий от tz4678

tz4678 ★★ (08.12.21 16:35:46)

autocommit можно включить/отключить… че угодно делать. читай маны.

Боюсь, что тебя можно отправить читать маны:

The “autocommit” feature of SQLAlchemy is a legacy feature that will be deprecated in an upcoming release. New usage paradigms will eliminate the need for it to be present. … This section discusses the feature within SQLAlchemy that automatically invokes the .commit() method on a DBAPI connection, however this is against a DBAPI connection that is itself transactional. For true AUTOCOMMIT, see the next section Setting Transaction Isolation Levels including DBAPI Autocommit.

Вообще, если ты не заметил, я тебе привел переключение на уровне РСУБД, и пример привел не просто так :)

Дальше бы, я бы тебя помацал бы на предмет: «Global Deadlock Detector» (я же не просто так сказал именно про MVCC, механизм который в РСУБД).

Короче, БДСМ-кот. Скучно.

tz4678 ★★ (08.12.21 16:35:46)

design by contract - «не нужно».

С чего ли? Глянул форумы питонистов, вполне себе реализуют они Design by Contract:

class Math:
    def square_root(self, number)
        """
        Calculate the square-root of C{number}

        @precondition: C{number >= 0}

        @postcondition: C{abs(result * result - number) < 0.01}

Через твои любимые «декораторы». Так что автох#й , насчет того, что якобы «не нужно».

tz4678 ★★ (08.12.21 16:35:46)

код на хацкеле - просто треш.

С чего ли? Ты его хоть понял, чтобы личностно-субъективные ярлыки вешать?

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 2)
Ответ на: комментарий от twinpeaks

Я это признаю, НО! подчеркиваю, что таких - меньшинство. Речь в треде - о грехах большинства.

Как ты определил, где меньшинство, где большинство? По посетителям LOR’а, которых два с половиной калеки?

Я пишу на Python 20+ лет, и большинство проектов вокруг меня хорошо структурированы и начали применять паттерны по делу задолго до других (например, Zope 3 была построена на dependency injection задолго до того, как большинство впервые услышали этот термин, а возможно даже до того, как он был придуман).

emorozov
()
Ответ на: комментарий от tz4678

tz4678 ★★ (08.12.21 16:41:01)

Напиши хотя бы один говносайт на джанге, потом не си свою ересь. Вот напиши его с применением всех своих любимых паттернов, и посмотрим, что получится

Уважаемый мальчик за «30 долларов в час» (https://github.com/tz4678 , ты сам же указал свой ценник на GitHub «Python/JavaScript programming 30$/h»). Я лично уже года три не работаю, как программист, уже давно DBA/DevOps.

Ранее писал и поверь, далеко не сранные говно-сайты, которые судя по гитхабу и по твоим частым упоминаниям пишешь именно ты.

Короче, иди димедрола покушай. Это то, что ты обычно на завтрак принимаешь в организм, видимо.

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 2)
Ответ на: комментарий от emorozov

emorozov (08.12.21 16:43:25)

Как ты определил, где меньшинство, где большинство? По посетителям LOR’а, которых два с половиной калеки?

Ну, дед мороз. Я же писал, что за последние несколько лет видел ряд проектов - на ряде фирм. Здесь в данном треде, еще один товарищ писал, что тоже самое.

Не исключаю, что может это «нам так везет», но у меня еще знакомые есть. И многие поговаривают, что «везде - всё тоже самое», касаемо Питонистов, как и работников другого стэка.

Ну ты - молодец, что у тебя все - четко и классно. Поздравляю и желаю, чтобы было побольше таких, как ты на рынке.

twinpeaks
() автор топика
Ответ на: комментарий от twinpeaks

многие поговаривают, что «везде - всё тоже самое»,

Точно могу сказать, что не везде. Более того, я не только на Python писал, и могу сказать, что на других языках тоже есть помойки.

Не уверен, что это связано с языком, хотя выше уже писал, что есть ощущение, что некоторые языки больше способствуют написанию говнокода, чем другие. Но доказать или опровергнуть это невозможно.

По ощущениям это больше от того, что абстрактное мышление — сложная штука и недоступна большинству людей просто физически, в силу ограничений строения мозга. Эволюция не готовила нас к такому.

Возможно, в языках, построенных на более высоких уровнях абстракции, говнокода будет меньше, но исключительно потому, что большинство людей способных хоть как-то наговнякать на Python/Perl/Bash/PHP/Java, не смогут освоить Haskell или Scala в принципе. Хотя и в этом не уверен.

На языках, построенных на более-менее одинаковых принципах, уровень говнокода вряд ли отличается более чем на десяток процентов.

emorozov
()
Ответ на: комментарий от tz4678

Для тех кто в танке: оно позволяет писать вот так вот:

А что из этого Java не умеет? И что в этом красивого?

так изящно ты ни на чем не напишешь… у питона есть недостатки реальные, о которых тролота не упомянула даже типа рассово неверной области видимости и тп

Я вообще не выделял конкретику. Но, ТС выделил вполне внятно недостаток тенденций сообщества.

small-entropy
()
Ответ на: комментарий от emorozov

вот в plain C напиши мне этот, как его, синглетон, пожалуйста

Ну вообще в Си как раз на файлах/модулях делается нормальный синглтон. Потому что функции неизменяемы, импортируются из файла, а данные объявляются static и скрываются. В отличие от пистона это всё работает. При том что это даже модулями официально не называется.

no-such-file ★★★★★
()
Ответ на: комментарий от small-entropy

Вопрос в лоб - а зачем галерею писать на PHP? Это вроде как задача фронта. или я чего-то не понимаю.

Я говорю про код, написанный до 2010 года. Тогда никто даже не использовал термины фронтенд/бэкенд.

Да и вообще неинтересно вспоминать, чтобы сравнивать PHP 2007 года и Python того же года. Просто пояснял, что где-то с 2007 года поставил в памяти зарубку: никогда не подходить к PHP на расстояние пушечного выстрела. И пусть сейчас это другой язык — всё равно не вижу смысла даже заглядывать туда. Во-первых, слишком сильны флэшбеки от того ужаса, что был тогда, даже спустя 15 лет. Во-вторых, если сейчас появится минутка лишнего времени, я лучше её на изучение Rust, скажем, потрачу.

Поэтому вы погрузились в Python, где ситуация ничуть не лучше?

Я не погружался в Python только что. Пишу на нём где-то с 1999 года, когда о нём у нас почти никто не слышал.

Сейчас только начал задумываться, что может быть стоит перейти на другой язык, по нескольким причинам, одна из которых - просто устал 20+ лет делать одно и то же.

Так что сейчас нашёл работу, где приходится также писать C++ код. Хочу осилить Rust, даже пописываю немного на нём, но дальше тривиальных вещей пока не продвинулся, т.к. совсем нет на это времени.

В общем, дело не в том, что я разочарован в Python или наоборот. Когда-то был влюблен в этот язык, во времена Python 1.5.2, когда он реально был похож на псевдокод, и альтернатив вообще не было. Сейчас отношение ровное.

Код на Python видел самый разный, но большая часть виденного была хорошо написана. Выше привёл пример, что Zope 3 использовал подходы, которые стали популярны сейчас, только лет этак на 14 раньше, когда для них ещё и названия не были придуманы.

emorozov
()
Ответ на: комментарий от tz4678

Уважаемый code monkey , ты синглтон-то не осилил, и не одупляешь ОО-дизайн и какой уровень дичи несешь. Я осилил в свое время DDD/CQRS+ES. А ты еще вякакаешь что-то про Haskell. Тебе молчать в тряпочку надо. Работай дальше за 30 долларов в час. Того гляди, я и сам найму тебя :)

twinpeaks
() автор топика
Ответ на: комментарий от twinpeaks

DDD/CQRS+ES.

А тут я слегонца порвался от смеха. Жги ещё! SignalR осилил?

anonymous
()
Ответ на: комментарий от emorozov

Я говорю про код, написанный до 2010 года. Тогда никто даже не использовал термины фронтенд/бэкенд.

Я тогда работал backend разработчиком, мой товарищ - frontend разработчиком. Что мы делали не так?

Да и вообще неинтересно вспоминать, чтобы сравнивать PHP 2007 года и Python того же года.

Утверждалось, что PHP был хуже Python. Раз утверждалось - сравнение проводилось. Вот и интересна конкретика.

Просто пояснял, что где-то с 2007 года поставил в памяти зарубку: никогда не подходить к PHP на расстояние пушечного выстрела.

То есть, вывод о том, что язык плохой был сделан по говнокоду какого-то Васяна. Но отторжение от таких же простыней на Python не вызывает отторжение. Странная позиция.

И пусть сейчас это другой язык — всё равно не вижу смысла даже заглядывать туда.

Ну хотя бы, чтобы понимать конъектуру рынка, кто и почему требуется, какие навыки оплачиваются. Внезапно - программист профессия, где знания становятся не репрезентативны очень быстро.

Во-первых, слишком сильны флэшбеки от того ужаса, что был тогда, даже спустя 15 лет.

Это простое оправдание лени. По такой логике я должен бояться как огня Python, забиваться в угол и плакать при одном упоминании этого ЯП.

Во-вторых, если сейчас появится минутка лишнего времени, я лучше её на изучение Rust, скажем, потрачу.

Rust - не плохой инструмент. Но есть мнение, что на любом языке можно написать нормально, но почему-то в Python сообществе это не так пропагандируется, как «хяк-хяк и в продакшн». Собственно тема ТС об этом и именно поэтому я свалил с этого стека пописав пять лет. Если честно, по моему опыту - лучше уж старый PHP-код, чем даже новые python-проекты в среднем по больнице. Бывают исключения, но редко.

В общем, дело не в том, что я разочарован в Python или наоборот. Когда-то был влюблен в этот язык, во времена Python 1.5.2, когда он реально был похож на псевдокод, и альтернатив > вообще не было. Сейчас отношение ровное.

Простите, но я сам начинал с ранних версий «змеи». И альтернатив у неё было «до одного места». Самый простой пример и на вскидку - Smalltalk, который был ещё больше похож на псеводкод и очень близкий примитивному английскому. Basic, который идеологический близкий к изначальному Python. Oberon, прозрачный и простой.

И, кстати, python был не популярен изначально и начал набирать хайп только во второй версии, где в него завезли кастрированные реализации всего подряд, за счёт чего его мог изучить кто угодно и писать код, который как-то работает.

Код на Python видел самый разный, но большая часть виденного была хорошо написана. Выше привёл пример, что Zope 3 использовал подходы, которые стали популярны сейчас, только лет этак на 14 раньше, когда для них ещё и названия не были придуманы.

Zope 3 не равно язык. ORM не равно язык. Они не имеют никакого отношения к дизайну языка или к его сильным/слабым сторонам. Внезапно большая часть современных фреймворков для web (если мы говорим о «полновесных») являются вариациями подходов, которые были сделаны ещё в Smalltalk/Seaside.

В целом же, «подходы» о которых вы говорите - вы так и не назвали. Ни одного паттерна, уникального и применяемого в Python и созданного сообществом.

small-entropy
()
Ответ на: комментарий от small-entropy

Я тогда работал backend разработчиком, мой товарищ - frontend разработчиком. Что мы делали не так?

Тогда не было такого деления (до 2010 года) в вебе. Были разработчики и были, например, верстальщики. Первые frontend фреймворки начали появляться где-то в 2010, и они не стали моментально популярными.

Я допускаю, что в паре мест возможно использовали данную терминологию, но не надо, пожалуйста, говорить, что она в 2007 или даже 2010 году была общепринятой. Совершенно точно не была.

Утверждалось, что PHP был хуже Python. Раз утверждалось - сравнение проводилось. Вот и интересна конкретика.

Кому сейчас интересно сравнение языков 14 летней давности. Можно найти на интернет-ресурсах сравнения. Толку разводить дискуссию из-за того, что давно прошло?

То есть, вывод о том, что язык плохой был сделан по говнокоду какого-то Васяна. Но отторжение от таких же простыней на Python не вызывает отторжение. Странная позиция.

Я не видел в те года кода на PHP, на который было бы приятно посмотреть. Ни в Open Source, ни в коммерческой разработке. Всё, написанное на PHP, было лютым говнокодом. Можно было открыть любой файл любого проекта и наслаждаться видом говнокода.

Возможно, что и сейчас так. Во всяком случае, я несколько лет назад взглянул на код Wordpress, просто из любопытства, и там был почти такой же говнокод, как и за 10 лет до этого.

Ну хотя бы, чтобы понимать конъектуру рынка, кто и почему требуется, какие навыки оплачиваются. Внезапно - программист профессия, где знания становятся не репрезентативны очень быстро.

PHP плохо оплачивался 15 лет назад, плохо оплачивается и сейчас. Мне не нужно смотреть на сам язык, чтобы это знать.

Это простое оправдание лени. По такой логике я должен бояться как огня Python, забиваться в угол и плакать при одном упоминании этого ЯП.

Лень тут не при чём. Я хорошо устроен, у меня много работы, и мало свободного времени. И свободное время я лучше потрачу на что-то, что мне либо интересно, либо принесёт какой-то профит в будущем. PHP не попадает ни в одну из этих категорий.

Второе соображение: я точно знаю, что 15 лет назад PHP был говном. Жизненного опыта уже достаточно, чтобы понимать, что из конфеты говно сделать просто, а из говна конфету сделать почти невозможно. Соотв-но, если кто-то хвалится, что смог из говна сделать конфету, тратить время на проверку этого тезиса нецелесообразно - скорее всего, человек заблуждается или обманывает.

но почему-то в Python сообществе это не так пропагандируется, как «хяк-хяк и в продакшн»

Не знаю, где это не пропагандируется. Я на каждом шагу видел и продолжаю видеть в сообществе статьи, как писать лучше. Это вообще фишка Python, сообщество всегда было ориентировано на то, чтобы писать понятный, поддерживаемый код. Мы, кажется, в какие-то разные сообщества смотрим.

Basic, который идеологический близкий к изначальному Python.

ТБМ. После этого, дальше я вас всерьёз воспринимать просто не могу.

emorozov
()
Ответ на: комментарий от emorozov

Тогда не было такого деления (до 2010 года) в вебе. Были разработчики и были, например, верстальщики.

Я же говорю, было. Мейби не везде. Но было. Да и это собственно не относится к теме. Ответов на заданные вопросы - так и нет.

Первые frontend фреймворки начали появляться где-то в 2010, и они не стали моментально популярными.

Frontend был и до. Менее востребованный, более простой. Фреймворки сделали его популярнее.

Я допускаю, что в паре мест возможно использовали данную терминологию, но не надо, пожалуйста, говорить, что она в 2007 или даже 2010 году была общепринятой. Совершенно точно не была.

В нормальных организациях - была. На фралансе и «рога и копыта», да. Не было, да и сейчас нет

Кому сейчас интересно сравнение языков 14 летней давности. Можно найти на интернет-ресурсах сравнения. Толку разводить дискуссию из-за того, что давно прошло?

Как минимум - общие тенденции развития языка, плюс - вы даёте однозначные выводы по своему опыту не сказав о репрезентативности опыта. Следовательно делаете своё мнение фактом. А факты требуют подтверждения.

Я не видел в те года кода на PHP, на который было бы приятно посмотреть.

Так видели или нет? Вы утверждали ранее обратное.

Ни в Open Source, ни в коммерческой разработке. Всё, написанное на PHP, было лютым говнокодом. Можно было открыть любой файл любого проекта и наслаждаться видом говнокода.

Вы не находите взаимоисключающие параграфы. В первом предложении вы говорите о том, что вы не видели кода, после утверждаете, что код видели и он г-но. Мсье, вы путаетесь в показаниях.

Возможно, что и сейчас так. Во всяком случае, я несколько лет назад взглянул на код Wordpress, просто из любопытства, и там был почти такой же говнокод, как и за 10 лет до этого.

Вы ранее говорили, что у вас не стоит смотреть в современный PHP. А тут даже WP смотрели, кишки. Вопрос актуальный зачем и как на основе движка для блока можно сделать вывод о языке - вопрос открытый. Если говорить о культуре кода - WP это некое legacy, которое используют просто чтобы быстро собрать визитку, ландос или каталог с заказом не программированием, а мышкой + мелкими допилками. Качественные продукты на нём не собирают, работают с ним в большей степени скрипт-киди и те, кого раньше называли «веб мастера». То есть местечковые вебстудии. К чему это? Это не репрезентативный проект для «понять в каком состоянии язык».

PHP плохо оплачивался 15 лет назад, плохо оплачивается и сейчас. Мне не нужно смотреть на сам язык, чтобы это знать.

Оплачивался и оплачивается +/- как Python. Разброс мидла PHP и Python 125-140 за 2021 в регионах. Но тема и вопросы не по ЗП.

Лень тут не при чём. Я хорошо устроен, у меня много работы, и мало свободного времени. И свободное время я лучше потрачу на что-то, что мне либо интересно, либо принесёт какой-то профит в будущем. PHP не попадает ни в одну из этих категорий.

Не факт. Языки - меняются, развиваются. За JS когда-то не платили столько, применяли для анимашек. Сейчас - 100500 способов применения, высокая ЗП (кстати, внезавно выше чем на Python).

Второе соображение: я точно знаю, что 15 лет назад PHP был говном.

По вашим же показаниям - ваше знание на уровне оценки песни «битлов» по тому, как Васян напевал в сортире.

Жизненного опыта уже достаточно, чтобы понимать, что из конфеты говно сделать просто, а из говна конфету сделать почти > невозможно.

Вот. И тут мы плавно подходим к мысли о том, что не сообщество Python такое, а язык объективно слабый и сообщество - его отражение.

Соотв-но, если кто-то хвалится, что смог из говна сделать конфету, тратить время на проверку этого тезиса нецелесообразно - скорее всего, человек заблуждается или обманывает.

Погодите, я такого не говорил. Я сказал, что Python ничем не лучше PHP и даже хуже по ряду вещей. Аналогично сообщества по уровню средней температуры по больнице. Но - вы утверждали, что из python сделали конфетку. Я же говорил, что PHP и Python были слабыми, но PHP хотя бы правят свои проблемы.

Не знаю, где это не пропагандируется.

Да ладно. От этого популярность Django заоблачна и море курсов «python за три дня для дегенератов».

Я на каждом шагу видел и продолжаю видеть в сообществе статьи, как писать лучше.

Содержание статей только чаще всего не об архитектуре, паттернах или подходах. А о сакральном смысле идентаций, того что язык «гибкий» и в нем можно мешать всё подряд чтобы быстрее писалось.

Это вообще фишка Python, сообщество всегда было ориентировано на то, чтобы писать понятный, поддерживаемый код. Мы, кажется, в какие-то разные сообщества смотрим.

Откуда тогда простыни процедурщины, куча микросервисов на Django, оправдание сообществом убогой реализации ООП и ФП? Пропаганда оформления, нейминга. Они только малая часть архитектуры.

ТБМ. После этого, дальше я вас всерьёз воспринимать просто не > могу.

А в чём критическая разница? Два языка, создаваемые для быстрых решений и обучения. Убого поддерживающие парадигмы, с убогим синтаксисом. Да, с разных языковых семейств. Но в целом - аналоги.

small-entropy
()
Последнее исправление: small-entropy (всего исправлений: 1)
Ответ на: комментарий от small-entropy

Frontend был и до. Менее востребованный, более простой. Фреймворки сделали его популярнее.

Покажите мне объявления о работе 2007-2010 года, в которых используется терминология «бэкенд/фронтенд». На web.archive.org наверное должны быть примеры в каждом втором объявлении, раз это было тогда принято.

Так видели или нет? Вы утверждали ранее обратное. Вы не находите взаимоисключающие параграфы. В первом предложении вы говорите о том, что вы не видели кода, после утверждаете, что код видели и он г-но. Мсье, вы путаетесь в показаниях.

Внимательно почитайте. Я написал, что не видел хорошего кода на PHP. Никакого противоречия нет.

А тут даже WP смотрели, кишки. Вопрос актуальный зачем и как на основе движка для блока можно сделать вывод о языке - вопрос открытый. То есть местечковые вебстудии

Смотрел не для того, чтобы сделать выводы, а потому что стало много делаться сайтов на WP, притом в них же стали находиться постоянно дыры, в общем, просто из любопытства решил посмотреть, что ж там под капотом у очень популярного решения.

На WP делается много сложных сайтов, не только местечковыми студиями. Просто рано или поздно их переписывают, т.к. WP не тянет и под капотом лапша, с которой толком ничего поделать нельзя.

Кстати, а кто в глобальном масштабе использует PHP-то, кроме местечковых студий? Кроме Facebook, да и в ФБ, подозреваю, PHP уже остался только как легаси.

не сообщество Python такое, а язык объективно слабый и сообщество - его отражение.

Что такое «объективно слабый язык». Приведите эти объективные критерии. Судя по вашему запалу, они у вас есть, и привести и обсуждать их будет намного проще, т.к. они типа объективные.

Даже я, говоря про PHP, говорю, что это субъективное мнение. Да, субъективное, и я субъективно зарёкся подходить к этому г-ну ещё 15 лет назад.

Пытаться найти какие-то объективные слова для PHP мне даже неинтересно. Этот язык в принципе утратил свою актуальность, также как perl, скажем. Нет смысла даже пытаться его критиковать. Умер Максим, и … с ним.

Содержание статей только чаще всего не об архитектуре, паттернах или подходах. А о сакральном смысле идентаций, того что язык «гибкий» и в нем можно мешать всё подряд чтобы быстрее писалось.

Да? Ну покажите примеры и тех, и тех, вместе с подсчётом процентного количества тех и других.

Я уже редко статьи про Python читаю, т.к. могу писать их (и пишу), но что-то я статей про индентацию не помню. Это скорее среди ненавистников Python было популярно лет этак 20 назад: «Ну как же можно заставлять всех использовать индентацию! Это ж дно!» Но этот источник давно иссяк.

Откуда тогда простыни процедурщины, куча микросервисов на Django, оправдание сообществом убогой реализации ООП и ФП?

На Django микросервисы не пишут. Django - фреймворк для монолитов, возможно, распределённых монолитов. Он не подходит для микросервисов, и оные на нём почти никто не пишут.

Реализация ООП в Python не убогая. Что в ней убогого-то? Конкретно, по пунктам.

Функциональное программирование на Python не очень хорошо ложится, т.к. Python - императивный язык, и Гвидо по своим причинам сопротивлялся и сопротивляется попыткам сделать написание функционального кода на Python проще. Хотя это всё равно возможно, и даже не так уж сложно.

Но я тут претензии не очень понимаю: каждый язык создаётся под какую-то парадигму, Python никогда и не претендовал на роль хорошего кандидата для ФП. Да и в реальной жизни ФП почти не взлетело. Концепция хорошая, но с реальной жизнью оказалась почти несовместима. И что?

emorozov
()
Ответ на: комментарий от twinpeaks

Через твои любимые «декораторы».

Где ты там декораторы увидел? Это один многострочный комментарий. Иди учи синтаксис, неуч, а потом уже учи других, как писать на их языке.

anonymous
()
Ответ на: комментарий от emorozov

Я как то делал небольшой проект на Джанго3 в старом и классовом исполение. По сути и так и так пашет, и время написания было одинаковым так что по фигу, кому что нравится то так и пишет.

mx__ ★★★★★
()
Ответ на: комментарий от small-entropy

Или давайте сравним со Smalltalk, на самом деле он эталонное воплощение для ООП языка. Чем Smalltalk/Pharo для примера хуже?

  1. тем, что никто его не юзает

  2. тем, что под ООП понимается обычно другое

  3. тем, что говна мутабельных стейтов везде

Смысл ООП

в его отсутствии

anonymous
()
Ответ на: комментарий от no-such-file

Ну вообще в Си как раз на файлах/модулях делается нормальный синглтон. Потому что функции неизменяемы, импортируются из файла, а данные объявляются static и скрываются. В отличие от пистона это всё работает. При том что это даже модулями официально не называется.

потому что в вашем pdp-шном ассемблере, натянутом на глобус, нормальных модулей нет и не будет

(питон тоже говно, но более человеколюбивое)

anonymous
()
Ответ на: комментарий от emorozov

потратить 20 лет жизни на работу программистом, чтобы на закате писать на C++, грустненько

anonymous
()
Ответ на: комментарий от anonymous

потратить 20 лет жизни на работу программистом, чтобы на закате писать на C++, грустненько

А на чём надо писать, чтобы было весело?

emorozov
()
Ответ на: комментарий от anonymous

тем, что никто его не юзает

Во-первых, я говорил в контексте дизайна языка и его возможностей. Во-вторых, Smalltalk до сих пор вполне успешно используется. Правда не в рашке. Тут, как правило, приживаются ущербные технологии/стеки вроде Python.

тем, что под ООП понимается обычно другое

Нет другого понимания ООП. Есть конкретная парадигма (кстати, основанная на акторной модели) и её эталонная реализация (crystall OOP, к которому относится Smalltalk и ещё пара языков). Есть заимствование конкретных идей парадигмы в мультипарадигменных языках.

тем, что говна мутабельных стейтов везде

Внезапно, это как раз про Python. ООП и Smalltalk как раз про изоляцию данных в первую очередь (акторная модель ведь) и запрет мутации стейта «извне», только «изнутри».

в его отсутствии

ФП и ООП очень близки, ФП тоже - нинужно?

small-entropy
()
Ответ на: комментарий от emorozov

Покажите мне объявления о работе 2007-2010 года, в которых используется терминология «бэкенд/фронтенд». На web.archive.org наверное должны быть примеры в каждом втором объявлении, раз это было тогда принято.

Я не в курсе как вы и что смотрите, я говорю по факту (две первые записи в трудовой - «разработчик бизнес-логики веб-сайтов» от одной нефтянной компании и «разработчик интерфейсов веб-сайтов» от одного интегратора аппаратуры для нефтянки). 2007-2010 год я искал работу backend на PHP и frontend на jquery. Как на рынка, так и на фрилансе. Аналогично мой друг и коллега.

Внимательно почитайте. Я написал, что не видел хорошего кода на PHP. Никакого противоречия нет.

У вас два тезиса было изначально - «код на РНР априори кал» и «РНР хуже Python». Это уже потом вы сказали что современного вы не видели и видели РНР только на примере какой-то странной задачи. А про настоящее вы не знаете, но смотреть лень и прочее.

Смотрел не для того, чтобы сделать выводы, а потому что стало > много делаться сайтов на WP, притом в них же стали находиться постоянно дыры, в общем, просто из любопытства решил посмотреть, что ж там под капотом у очень популярного решения.

На WP делать дешево, можно не нанимать программистов и продавать коробочные решения. Дыры - не проблема языка, это проблема тех кто берёт модуль от Васяна бесплатный и втыкает его. То, что это стало «всплывать» - следствие популярности WP. В случае аналогичного количества использования той же Django - думаю ситуация будет не сильно лучше.

На WP делается много сложных сайтов, не только местечковыми студиями. Просто рано или поздно их переписывают, т.к. WP не тянет и под капотом лапша, с которой толком ничего поделать нельзя.

В целом любая технология ограничена. WP - блоговый движок, пусть и популярный. Да, на нём уже есть наркоманы, которые делают API. Но это не значит, что это эффективное решение. И проблему тут не в языке, а в целом архитектуры WP, который делался для блогов и визиток.

Кстати, а кто в глобальном масштабе использует PHP-то, кроме местечковых студий? Кроме Facebook, да и в ФБ, подозреваю, PHP уже остался только как легаси.

На WP делается много сложных сайтов, не только местечковыми студиями. Просто рано или поздно их переписывают, т.к. WP не тянет и под капотом лапша, с которой толком ничего поделать нельзя.

Кстати, а кто в глобальном масштабе использует PHP-то, кроме местечковых студий? Кроме Facebook, да и в ФБ, подозреваю, PHP > уже остался только как легаси.

Внезапно, но много где. Для примера можно глянуть тут (https://www.softkraft.co/companies-using-php/).

Что такое «объективно слабый язык». Приведите эти объективные критерии. Судя по вашему запалу, они у вас есть, и привести и > обсуждать их будет намного проще, т.к. они типа объективные.

Да, есть. Я для себя выделил несколько простых критериев. Но, всё же - вопрос мой прозвучал раньше и касался он даже не теории разработки языков. С радостью перейду на обсуждение дизайна Python и критериев хорошего языка программирования, после того как получу ответы на заданные вопросы.

Даже я, говоря про PHP, говорю, что это субъективное мнение. Да, субъективное, и я субъективно зарёкся подходить к этому г-> ну ещё 15 лет назад.

Субъективное мнение появилось гораздо позже в высказываниях, после того как начал задавать вопросы). Поэтому перейдём всё же к ответам на заданные вопросы.

Пытаться найти какие-то объективные слова для PHP мне даже неинтересно. Этот язык в принципе утратил свою актуальность, также как perl, скажем. Нет смысла даже пытаться его критиковать. Умер Максим, и … с ним.

О-да. И Perl мёртв и PHP. Только Python, только Django. Вам самому-то не смешно?

Да? Ну покажите примеры и тех, и тех, вместе с подсчётом процентного количества тех и других.

Кто такие те? Кто какие другие? Почему я вам какую-то статистику должен считать за вас? Тем более она будет в любом случае бесполезная. Если даже будет 99% статей уровня «говнокодим с Васяном», то вы скажите «вам лень смотреть на неё». Ну или скажите, что выборка сделана по не тем ресурсам.

Я уже редко статьи про Python читаю, т.к. могу писать их (и пишу), но что-то я статей про индентацию не помню.

Это был сарказм. Я про, то что уровень статей на Python чаще всего уровня «Привет, Мир» на библиотеки Х. То, что вы не читаете статей/трудов по архитектуре - тоже показатель, как части сообщества программистов python.

Это скорее среди ненавистников Python было популярно лет этак 20 назад: «Ну как же можно заставлять всех использовать индентацию! Это ж дно!» Но этот источник давно иссяк.

Идентация спорное решение и явный косяк в дизайне языка. Ну да ладно, не об этом. Я не ненавистник Python. А человек, который сбежал из этого стека по названным ТС причинам.

На Django микросервисы не пишут.

Вы не поверите). Я могу сходу вам показать 5-10 компаний за последние пол года, просто открыв оферы, которые мне присылали. Могу назвать крупные компании которые так делают.

Django - фреймворк для монолитов, возможно, распределённых монолитов. Он не подходит для микросервисов, и оные на нём почти никто не пишут.

В реальном мире пишут. К сожалению. Выше уже описал.

Реализация ООП в Python не убогая. Что в ней убогого-то? Конкретно, по пунктам.

Инкапсуляции нет, наследование множественное, фактически абстрактных классов нет, полиморфизм слабый, обмена сообщениями как метода общения между объектами нет… Продолжать?

Функциональное программирование на Python не очень хорошо ложится, т.к. Python - императивный язык, и Гвидо по своим причинам сопротивлялся и сопротивляется попыткам сделать написание функционального кода на Python проще. Хотя это всё равно возможно, и даже не так уж сложно.

Python не плохо ложится синтаксически в ФП, но у него есть проблемы иного рода. И связаны они как раз с его дизайном и назначением. Нет у Python задачи быть чистым ФП языком, так как при обучении этого не нужно. В прототипе, который надо выкинуть через пол года максимум - тоже не нужно, так как важна скорость наговнокодить и проверить гипотезу. Но что-то вы правильно заметили - Python это обычный императивный язык с огрызками других парадигм, которые позволяют упростить декомпозицию императивного кода.

Но я тут претензии не очень понимаю: каждый язык создаётся под какую-то парадигму, Python никогда и не претендовал на роль хорошего кандидата для ФП.

Простой вопрос - под какую парадигму Python создавался? Давайте посмотрим.

Да и в реальной жизни ФП почти не взлетело.

ФП как и ООП, как и любая другая парадигма - определённый круг задач. И в определённых задачах ФП вполне себя хорошо чувствует. В отличии от Python, которому есть альтернативы куда лучше в любой задачи. Его популярность обусловлена примитивностью, которая позволила наплодиться разным вайтишникам.

Концепция хорошая, но с реальной жизнью оказалась почти несовместима. И что?

Расскажите о ненужности ФП в высоконагруженных продуктах, где применяются Scala, Erlang, Elixir, etc. Мне будет интересно на самом деле, как вы докажете какому-нибудь телекому, что пора выбросить ФП и перейти на православный Python.

И да, вы всё ещё уходите от конкретных вопросов. Чем Python лучше PHP в плане дизайна языка? Чем модульная система Python лучше Rust? Чем стандартная библиотека Python лучше Ruby? Чем Python проще Smalltalk? Ну и ещё куча заданных.

small-entropy
()
Ответ на: комментарий от small-entropy

Чем Python лучше PHP в плане дизайна языка?

$ же.

LamerOk ★★★★★
()
Ответ на: комментарий от small-entropy

Я не в курсе как вы и что смотрите, я говорю по факту (две первые записи в трудовой - «разработчик бизнес-логики веб-сайтов» от одной нефтянной компании и «разработчик интерфейсов веб-сайтов» от одного интегратора аппаратуры для нефтянки). 2007-2010 год я искал работу backend на PHP и frontend на jquery. Как на рынка, так и на фрилансе. Аналогично мой друг и коллега.

Ну это же очевидная ложь, что вы всех за дураков держите? Открыл на web archive десяток вакансий за 2008-2009 год (именно 2010 не открывается, т.к. там hh использовал видимо рендеринг xslt, который web archive не смог архивировать).

Ни в одной вакансии нет слов «бэкенд», «фронтенд», и даже намёка.

Честно говоря, результат я знал и так, просто поражает ваше желание открыто соврать, лишь бы настоять на своём.

emorozov
()
Ответ на: комментарий от small-entropy

тем, что под ООП понимается обычно другое

Нет другого понимания ООП. Есть конкретная парадигма (кстати, основанная на акторной модели) и её эталонная реализация (crystall OOP, к которому относится Smalltalk и ещё пара языков). Есть заимствование конкретных идей парадигмы в мультипарадигменных языках.

есть другое понимание ООП.

например, берём акторную модель Хьюита. классические пассивные POD данные + активные процессы (из, например, Ады) становятся активными данными (активными объектами, акторами) у которых «посылка сообщения» эвфемизм для behaviour-driven goal-oriented рефлексов и стимулов, которые хочет обрабатывает, не хочет – селектор :doesNotUnderstand и маршрутизирует тому ,который понимает. то есть, скорее селф или смоллток-72 чем смоллток-85.

берём ООП в стиле CommonLisp. по построению исторически это мутант из MacLisp, InterLisp, Genera ZetaLisp (которые ближе к прототипному). но тут ближе, внезапно, к фреймовой модели. где AMOP=метаобъектный протокол с мультиметодами и change-class в динамике. ну или Julia + мультиметоды, или nim + мультиметоды. суть в том, что мультиметоды приводят к более другому ООП, чем первое (акторное). и полезная рефлексия на метаклассах.

берём ООП в стиле scheme. то есть: сделай сам костыль на замыканиях, корутины или исключения или вот ООП. внезапно, схема появилась тоже как попытка акторную модель воткнуть в гигиеничные макросы через монады и синтаксические трансформеры. то есть, это ООП ближе к функционально-объектному, типа монад в хаскеле.

берём ООП в стиле смолток-85. почти акторная из смоллток-82, селф, только больше метаклассов богу метаклассов.

берём селф, ио, жаваскрипт. прототипное ооп. луа с метатаблицами, или вот пример выше про метакласс с метатаблицами. пытаемся фиксить Fragile Base Class problem из C++.

берём смоллток и си. получаем Objective C.

берём Simula-67 и си. получаем C++. метод virtual нужен, ООП низкоуровневое.

берём P-code и верификацию, упрощаем C++. получаем JVM. virtual не нужен, дефолты другие – но ООП всё ещё низкоуровневое.

берём CLR + extension methods, усложняем Java. получаем C#.

берём Eiffel и ковариантность ( X: LIKE ? ), контракты, множественное наследование, трансляцию в си, системную корректность через контракты. получаем немного другое, но в целом похожее на С++ ооп.

берём дельфи, JPI Modula-2, XDS Modula-2, Modula-3, Ada, Oberon-2, Component Pascal (Oberon-2), Active Oberon (A2).

получаем всё то же ООП в стиле С++. блин, да даже HLA = high level assembly здесь (синтаксис паскаля, семантика С++, но внутри ассемблер) == это всё ещё ООП в стиле С++.

немного выделяется из предыдущего пункта Ada (параметрический полиморфизм модулей, пакетов) и активный оберон (ближе к акторной модели из-за активных объектов и ASYNC/AWAIT не в тасках ады, а в активностях объектов).

но тоже примерно всё то же самое.

anonymous
()
Ответ на: комментарий от anonymous

Ada83, кстати показывает что объектный и объектно-ориентированный не одно и то же. Ada83=объектный не объектно-ориентированный. Ada95, Ada2005, Ada2012 = более ориентированный.

подход в аде: системный язык программирования. в котором нужно на уровне битов и байтов, раскладки типов и представления, классов памяти (контролируемые типы, тегируемые типы, пулы объектов) всё отдельно индивидуально задавать. и отдельно пассивные объекты, активные таски, исключения. прагмы для ограничивания подмножества языка, SPARK для контрактов (времени компиляции в том числе), верификации.

подход в обероне-2, компонентном паскале: жопа с ручкой (сборщиком мусора) и синглтон в модуле kernel.

подход в активном обероне: прикладной язык программирования, в котором async/await выделяется явно на уровне активностей активных объектов (в отличие от обычных, пассивных или POD).

ну и ещё что-то вроде того же nim,D,HLA того же можно выделить. где отдельные завязки на рантайм более(nim) или менее(D) гибкого (HLA, CTFE) ООП можно выделить.

ну или тот же Go, Rust. с настраиваемым рантаймом. где либо ad-hoc полиморфизм интерфейсов, либо семантика владения/одалживания но в общем, похоже – трейты вместо классов, агрегация вместо наследования.

или вот монады выделить и функционально-объектное. не суть скала или F# с active record, да вот хотя бы тот unikernel OS Mirage на Ocaml. где драйвер или протокол это функтор времени компиляции, то есть, интерфейс высшего порядка, то есть – метаобъектный протокол.

…. так о каком «одинаковом везде» ООП ты тут говорил?

походу, понимание ООП везде разное.

anonymous
()
Ответ на: комментарий от small-entropy

Расскажите о ненужности ФП в высоконагруженных продуктах, где применяются Scala, Erlang, Elixir, etc. Мне будет интересно на самом деле, как вы докажете какому-нибудь телекому, что пора выбросить ФП и перейти на православный Python.

вот, кстати, сравнивая Elixir и Python. заметно же, что первый – это попытка сделать второй на более функциональном рантайме от эрланга. тут тебе и синтаксис похожий, хайповый, новомодный с идентациями.

но всё-таки, скорее функциональщина. а не объектно-функциональщина с GIL.

anonymous
()
Ответ на: комментарий от small-entropy

ФП в высоконагруженных продуктах, где применяются Scala, Erlang, Elixir, etc.

А можно вопрос для общего развития. Ядро это высоко нагруженный продукт или нет ? А ютуб это высоко нагруженный продукт или нет ? Помню до покупки ютуба гуглом он был весь на руби.

mx__ ★★★★★
()
Ответ на: комментарий от mx__

Поправлю: тытруба была написана на Python (может быть и остаётся). Точнее, первая версия была сделана на PHP, но уже через три месяца переписана на Python. Что там сейчас — никто не знает, но вроде бы, используется несколько языков: Python, Go, Java, C++.

А вообще, мне кажется бессмысленно обсуждать что-то с человеком, который постоянно натягивает сову на глобус («в 2008 году существовало деление разработчиков на фронтенд и бэкенд», «питон - не оо язык», «питон похож на БЕЙСИК», и т.д. и т.п.).

Пускай дальше живёт в мире своих фантазий.

emorozov
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.