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

А без культуры проектирования и разработки результат будет как всегда. Это всегда так.

а что там преодолевать захардкоженное ограничение на папки и группы?) Особенно учитывая что мб телега как коробочное решение не предполагалось ))

Так я и пишу, что добавить второй вызов без лимитов.
Прямо как в одной известной операционной системе, где в API диалогов выбора файла 6 штук.

Это признак очень плохого и непродуманного дизайна.

а почему? что в этом плохого?

Кажется, тут нет дискуссии, а просто с одной стороны идут рассуждения в стиле «как-то запустить продукт, работают же, бизнес крутится как-то» - а с другой «реализовано без инженерных подходов, есть плохие и не продуманные решения, колхоз»

Одно другому то никак не мешает :)

Да всё хорошо. Продать же можно и 1С-Битрикс.

Просто от разрабов Битрикса сложно ожидать что-то сложнее умения есть ложкой не ковыряя одновременно рукой в носу.

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

>А здесь - олимпиадники, там если протокол жопоголовый, то связываться с ними корпам вдвойне опаснее чем с программистами Битрикс.

я вот это пожалуй внесу в фонд золотых цитат, с вашего позволения

Видишь ли.
Компетенции людей из Битрикса — поставка плохого продукта, который можно хоть как-то допилить под небольшой бизнес.

Там нет никакого полёта мысли, дизайн — типичное приложение ПоХаПэ. Админить это могут все. Поддерживать — почти все, кто умеет сдерживать рвотные позывы.

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

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

И если посмотреть на советскую гражданскую радиотехнику, то зная про подъезды не возникает вопросов, почему она так погано спаяна. А зная про репрессии не возникает вопросов, почему военная радиотехника настолько лучше.

Все эти вещи очень глубоко взаимосвязаны.

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

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

есть маленький нюанс - мессенджер никто не допиливает под свои "совершенно уникальные" процессы

не согласен, код пхпшников растет в стоимости поддержки нелинейно

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

Для 99,99 арх проблем олимпиадники не нужны, из них для 99,99% они вредны. И только "о малое" без них не обойдется. И скорее всего это будет не архитектурная задача, а алгоритмическая, максимум, преодолевающая жесткое архитектурное ограничение.

Фесбучег вам в контрпример

который написал свой интерпретатор для пхп? ну инстаграм еще добавь - у них свой инетрпретатор для питона из-за этого же

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

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

Алгоритмическую задачу решать будет не скубент, который катается по олимпиадам, а профессор. Иначе результатом будет MTProto.

Потому что это телеграмм и оно не работает без разработчиков.

до выхода похапе 7 была космическая экономия в плане железа