LINUX.ORG.RU
ФорумTalks

Ресурсов альтернативных взглядов на программирование тред

 ,


0

2

Недавно мне в копилку подкинули замечательный сайт:

https://phpthewrongway.com/

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

Я уже давно почитываю обсуждения на hackernews и WikiWikiWeb (например, http://wiki.c2.com/?XmlIsTooComplex ). К сожалению в них существует та же проблема, что и в интернете в целом: очень много мусора, то есть, шаблонных бездумно копируемых «собственных» точек зрения, подтвержденных богатым опытом из пяти угробленных «не мной» за последний год проектов.

Как человеку, который поддерживал годами проекты, над которыми сам работал, и который понимает, чего стоят многие книжные знания, мне, тем не менее, совсем не достаточно своего опыта и интересен аналогичный опыт других людей. Например, когда Дан Абрамов писал-писал годами компоненты в реакте на миксинах, чтобы потом в итоге заявить Mixins Considered Harmful и Mixins Are Dead. Long Live Composition. Ну и из классики — мой любимый Дейкстра, конечно.

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

★★★★

Ресурсов альтернативных взглядов на программирование тред

Скажи, пожалуйста, то же самое, но по-человечески.

dexpl ★★★★★
()

Ресурсов альтернативных взглядов на программирование тред

По моему опыту: смотрите, какие авторы вам интересны. Заходите на реддит, читайте комментарии.

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

По моему опыту: смотрите, какие авторы вам интересны. Заходите на реддит, читайте комментарии

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

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

Ресурсов альтернативных взглядов на программирование тред

Скажи, пожалуйста, то же самое, но по-человечески

Это негативное определение, то есть «что-то, что не похоже на то, что все знают», потому ему довольно тяжело дать конкретное определение.

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

http://govnokod.ru/

Да говнокода мне на работе фатает, меня все-таки интересует интегрированный и проанализированный собственный опыт, а не просто «посмотрите, какой бред я тут нашел».

byko3y ★★★★
() автор топика

какой-то адский поток сознания.

Я за бан наркомана

zgen ★★★★★
()

Вспомнил еще одного чела, который такую солидную серию статей написал по теме, у него вроде даже книга есть:

https://www.tedinski.com/

byko3y ★★★★
() автор топика

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

t184256 ★★★★★
()

Тебе альтернативные (специализированные/продвинутые) взгляды нужны или наркомания? Если первое то смотри на всякие MapReduce, модели акторов и иже с ними, которые не про классические штуки (семафоры и мьютексы). Я привёл пример с параллельными вычислениями, но аналогичные штуки есть практически во всех отраслях и направлениях программирования. Если второе, то вон метапрог есть...

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

Ну Brent Roose, но у него, как мне кажется, несколько пыхоспецифичные статьи

Почитал. Там не то что PHP-специфично, а даже Laravel-специфично. Я очень хочу наконец, чтобы кто-то с пруфами обосрал этот ларавель. Из обсуждения сайта «PHP: The Wrong Way» на Hacker News:

https://news.ycombinator.com/item?id=12319823

Позиции сторон примерно такие: зачем костылить свои велосипеды, когда можно взять готовый велосипед? — Зачем брать один из десятков чужих кривых конкурирующих меж собой велосипедов, которые даже не были расчитаны под твои задачи, если собственный велосипед хотя бы проще и подвластен тебе?

То же про докер. Почему-то IKEA-эффект, который почему-то не сработал с тем же докером. Docker, Laravel, Django, MS Office строили маркетинг на примерно той же идее — обучись один нашему единственному продукту на рынке, и тебе больше не нужно будет учиться. А чтобы заманить пользователей из других фреймворков, естественны, мы беспорядочно фаршируем наш фреймворк фичами. Получается безумно перегруженный монстр с сомнительными преимуществами, но все договорились пользоваться им, потому как-то и не особо замечают.

У меня есть большие подозрения, что Laravel сильно хуже, чем его рисуют, но среди пользователей Laravel почти нет тех, кто видит его реальные недостатки. У меня нет желания погружаться в Laravel, чтобы предоставить пруфы. Я слегонца уже погрузился в джангу, и боже упаси меня когда-то писать на ней сайты — это лапшемонстр, отдельные простенькие ручки управления которым выведены наружу и на первый взгляд он кажется нестрашным, но как только задача хоть немного становится нестандартной — всё, караул, сложность разработки взлетает в космос.

И да, у меня был собственный глубокий опыт с Vue.js, когда я долго не мог понять, зло это или добро. Сейчас, спустя несколько лет опыта разработки в команде, я вижу, что:

 — безруких программистов могила исправит. React/Vue, обязательно подкрепленный надзирателем с плеткой, может помочь заставить криворучек делать простенькие модули и не мешать остальным программистам. В случае сложных фич не спасет ничего;
 — архитектура и реализация Vue находится на сомнительном уровне, который лишь немногим выше уровня разрабов средненькой галеры. Альтернативу вполне реально написать, и еще более переоценены готовые решения под Vue, особенно учитывая то, как Vue вообще недружелюбно к JS-only коду.

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

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

Ну Brent Roose, но у него, как мне кажется, несколько пыхоспецифичные статьи

Не, сорян, я закапываю этого чела. Это книжный червяк (позвольте я опущу детали того, как я это понял), который треть усилий тратит на потребление стороннего опыты сомнительного качества, треть усилий тратит на его пересказ, и треть усилий тратит на площадки для распространение этих пересказов (в том числе https://aggregate.stitcher.io/). К сожалению, это тот случай, когда человеку толком говорить не о чем.

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

Я очень хочу наконец, чтобы кто-то с пруфами обосрал этот ларавель

Для чего? Это обыкновенный фреймворк, который не рекламировали как волшебную пилюлю от всего.

Позиции сторон примерно такие: зачем костылить свои велосипеды, когда можно взять готовый велосипед? — Зачем брать один из десятков чужих кривых конкурирующих меж собой велосипедов, которые даже не были расчитаны под твои задачи, если собственный велосипед хотя бы проще и подвластен тебе?

РНР предоставляет возможности для минимального горожения велосипеда, фреймворк часто нужен для более лёгкой поддержки.

Docker, Laravel, Django, MS Office строили маркетинг на примерно той же идее — обучись один нашему единственному продукту на рынке, и тебе больше не нужно будет учиться

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

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

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

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

Не знаю, про каких всех вы говорите (при живых альтернативах), но монстр — это когда в один фреймоврк пихаете компоненты симфонии и плагины.

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

Возможно, фанатики и рисуют его как серебряную пулю, но это, конечно же, не так.

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

Я очень хочу наконец, чтобы кто-то с пруфами обосрал этот ларавель.

Автор что, один из тех, кому написать что-то полезное другим мешают плохие ЯП и фреймворки? «Вот если везде бы был хускель, то я был бы Лев Толстой, ну а так я *** простой». Обосрать родившийся инвалидом пых-пых много ума не надо, тем не менее он работает и делает что-то полезное для других. В отличии от ТС.

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

А мы точно про одного и того же человека?

https://stitcher.io/blog/we-dont-need-runtime-type-checks

«I called them transpiled generics back then, but runtime-erased or runtime-ignored generics is probably a better name.»

Чел просто притащил фичи из других языков (Java, Python), при том, что от этих фич в исходных языках плюются. Так сказать «какой глобус лучше подойдет нашей сове?». Для уровня «здравствуйте, я хочу изучать PHP, но мне не нравятся некоторые его фичи» — этого понимания достаточно. Для уровня глубокого понимания языка это не прокатывает, потому что в PHP, как и в питон, в принципе нельзя всунуть те фичи, которые он хочет — понимание этого факта и есть один из симптомов глубокого понимания языка. Ну то есть засунуть эти фичи в язык вроде как и можно, но получится совершенно иной язык, и, по-хорошему, реализацию вместе со стандартной библиотекой тоже нужно будет с нуля переписывать. Что по итогу сделали в Hack, о чем он пишет в статье, но не показывает понимания причины этого решения. Я подчеркиваю, что это не просто мое личное мнение — в статье он сам ссылается на подобные ответы от других разрабов.

К своему стыду, пару лет назад я написал очень похожую статью, правда, в то время с питоном я был знаком довольно поверхностно. Чтобы ты понимал разницу между мной и ним — он год назад написал книгу: https://laravel-beyond-crud.com/ . Он до сих пор толком не разобрался в языке, а уже пишет книги и учит других. Это тот самый тип «программистов», которые на собраниях постоянно любят мозги своими охренительными идеями, придуманными пять минут назад, вместо того, чтобы проанализировать их самостоятельно и выдать какую-то более-менее целостное предложение.

Запомнил эти мои тезисы? Теперь с ними переходим к следующей статье:

https://stitcher.io/blog/dont-write-your-own-framework

Краткое содержание: я вышел на улицу, споткнулся и сломал руку — ПАЦАНЫ, НЕ ВЫХОДИТЕ НА УЛИЦУ, СИДИТЕ ДОМА. Он то ли кретин, то ли точно наоборот — очень сообразительный и наблюдательный чел, который пиарит свою книгу, причем, вполне возможно, что описанной в статье проблемы никогда не существовало — но это не имеет значения, поскольку проверять этого все равно никто не будет. Есть двести способов жидко обосраться по безопасности сайта, с готовым фреймворком и без него — он просто приводит один из способов это сделать, и почему-то присваивает эту проблему не кривым рукам, не безответственности какого-то отдельного программиста, не (боже упаси) порочным практикам программирования в его команде, а всем самописным фреймворкам в мире, которых он, естественнно, никогда в глаза не видел.

И после этого ты мне пишешь «Это обыкновенный фреймворк, который не рекламировали как волшебную пилюлю от всего» — вот же рекламируют, как волшебную пилюлю, пусть не ото всех, но от большинства болезней в мире PHP.

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

Чел просто притащил фичи из других языков (Java, Python),

В джаве нормальные дженерики, в питоне, ЕМНИП, тоже.

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

Эм, нет.

Краткое содержание: я вышел на улицу, споткнулся и сломал руку — ПАЦАНЫ, НЕ ВЫХОДИТЕ НА УЛИЦУ, СИДИТЕ ДОМА

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

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

И после этого ты мне пишешь «Это обыкновенный фреймворк, который не рекламировали как волшебную пилюлю от всего» — вот же рекламируют, как волшебную пилюлю, пусть не ото всех, но от большинства болезней в мире PHP.

Господи, даже его сайт не использует ларавел, что вы несёте? Что дальше, заговор пользователей ларавел?

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

В джаве нормальные дженерики, в питоне, ЕМНИП, тоже

Брент Руз подходит к вопросу со стороны «как бы нам заиметь обобщения в PHP?», я подойду к вопросу со стороны «а зачем нам вообще нужны обобщения?». И я еще раз напоминаю его псто:

https://stitcher.io/blog/dont-write-your-own-framework

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

Так вот, прежде всего статическая проверка типов (я сейчас не про обобщения) начиналась вводиться в компилируемых языках для ПРОВЕРКИ КОРРЕКТНОСТИ программы. Не для упрощения рефакторинга, не для подсказки аргументов в IDE (IDE в то время не существовало). Кстати, показательно, что в первоначальных версиях Си статической проверки типов не было. Если статическая проверка обобщений не позволяет проверить корректность программы — какая к черту разница, есть ли такая проверка в языке или нет? Я пойду даже дальше: если обобщенная проверка типов не позволяет повысить надежность приложения, то ее категорически нельзя вводить в язык, поскольку это приведет к бессмысленному усложнению разработки и поддержки самого языка.

Теперь из этих тезисов можно вывести причину, почему в питоне нет «нормальных обобщений»: утиная типизация и гибкость типов стандартной библиотеки в питоне приводит к тому, что корректный код вызывает ложное срабатывание ошибки типов, и при этом валидатор умудряется пропускать ошибки, вызыванные работой хуков, декораторов, функций стандартных библиотек, и прочей радости. Таким образом статическая проверка создает иллюзию надежности, которой на самом деле нет, и отвлекает ложными ошибками от настоящих ошибок. Более тонкой проблемой является то, что данные инструменты типизации склоняют разработчика к использованию худших моделей построения архитектуры в питоне — только для того, чтобы вписаться в ограничения системы типов и по максимуму избежать некорректной валидации. По этим причинам старая статическая проверка типов (как с обобщениями, так и без них) показала свою несостоятельность, и на замену ей пришла новая:

https://www.python.org/dev/peps/pep-0544/ — PEP 544 — Protocols: Structural subtyping (static duck typing)

Может быть это и не самый лучший вариант, но старый был абсолютно точно бесполезным мусором. Но Брент Руз ничего не слышал об этом и усердно продолжает топить именно за тот старый вариант статической проверки типов питона без проверок в рантайме, который уже доказал свою несостоятельность на практике. Да, проверки типов в рантайме, действительно, не особо полезны, правда, и без них ситуация не изменится, потому что проблема заключается вообще не в этих проверках типов, а в отсутствии эффективных инструментов проверки корректности работы программы. Для создания которых, между прочим, совсем не обязательно опираться на понятие «тип» и утыкивать код с ног до головы мусорными повторяющимися объявлениями аля C++.

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

Эм, нет

Надеюсь стало немного яснее, почему все-таки «эм, да».

Нет, краткое содержание: мы попробовали сделать свой фреймворк, оказалось, что это сложно, мы допустили ошибку и занимались сексом с ним на протяжении 3-х дней, не пишите свои фреймворки

А теперь объясни мне, почему из этого не следует вывод «они — рукожопы, и им нельзя поручать ответственные задания»? Который мне кажется очень вероятным, учитывая общую картину подхода к работе.

Господи, даже его сайт не использует ларавел, что вы несёте? Что дальше, заговор пользователей ларавел?

Сайт? У «сайта» нет динамического контента вообще, но он умудрился сделать этот сайт на PHP. Он из отряда тех ребят, которые также делают статичные текстовые странички с картинками в виде SPA на пустой HTML странице, которая подгружает весь контент динамически. Я понимаю, что во PHP-фреймворках происходит порнуха похлеще, когда поверх этого добавляется СУБД и на каждый запрос скрипты на пыхе неустанно каждый раз будто в первый раз перечитывают конфигурацию, определяют способ подключения к БД, потом отправляют сам запрос данных к БД, и дальше преобразовывают ответ от БД в HTML страничку, или даже JSON, который уже обрабатывает клиентское SPA. Но это никак не оправдывает Брента, который сделал свой пыхосайт просто менее порнушным.

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

А из того с чем сталкивался, для веба есть что-то достойное, или все тлен?

TypeScript. Нужно понимать, что разработка на JS совершенно не похожа на разработку на Java или C++, потому не нужно пытаться натягивать приемы из одной сферы в другую:

http://deplinenoise.files.wordpress.com/2017/03/webtoolspostmortem.pdf

Челы сделали почти все ошибки, который можно было сделать. Но у них есть оправдание — им сказали «веб это просто». По итогу JS версия провалилась и ее разработка была заброшена. А истина такова, что веб — это сложно, у него очень много специфики, которую, в принципе, можно побороть, если иметь в штате хороших веб-кодеров, но отдельные ограничения можно побороть только нативизацией приложения, хотя бы частичной.

Простой кроссплатформенный веб-сервис из текстовых страничек с картинками и минимумом динамичности? Хорошо, веб подходит. Адовая динамика с тысячами сущностей на одной странице, WYSIWYG редакторы, взаимодействие с хостовой ОС? Лучше сразу делай натив — не нужно будет по два раза переделывать.

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

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

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

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

Так доказал, что тайпскрипт активно развивается и вполне себе состоятелен?

А теперь объясни мне, почему из этого не следует вывод «они — рукожопы, и им нельзя поручать ответственные задания»?

Следует, чего же нет? Только он стоит рядом с выводом «писать свой фреймворк сложно».

Сайт? У «сайта» нет динамического контента вообще, но он умудрился сделать этот сайт на PHP

Это вы про статические сайты не слышали.

Но это никак не оправдывает Брента, который сделал свой пыхосайт просто менее порнушным

Вы так распинались, рассказывая как он рекламирует ларавел, взял бы jigsaw.

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

Да, вижу довольно часто хвалят TypeScript, надо подробнее ознакомиться.

А из моего опыта, был как раз свидетелем строительства велосипеда на PHP вместо использования фреймворка, печальное зрелище. Разработчик к второму-третьему проекту уже сам запутался в кодовой базе, в итоге после причесывания у нас получается тот самый «свой фреймворк», который нужно и в плане безопасности поддерживать, и дописывать уже готовую везде функциональность. Вряд ли у средней веб-студии достаточно ресурсов, времени и знаний чтобы этим заниматься, поэтому и Laravel/Yii во все поля.

Еще насчет нативности, клиенту нужно была что-то типа ERP и софт для взаимодействия с оборудованием. И делалось все это на вебе просто потому-что так умели здесь и сейчас, а клиента упускать нельзя. Кажется даже что-то на WebUSB городили. Причем, конечно, преподносилось это как преимущество, доступ с любого устройства, скорость внесения изменений и т.д. Но тут ничего нового, выбор технологии зачастую завязан на возможности разработчиков и бизнес интересы, а не свободный выбор более подходящей технологии.

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

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

Если бы он банально рассказывал историю, то у меня не было бы вопросов. Проблема как раз в том, что он не «банально рассказывает историю», а делает мудацкие обобщения и конкретные указания.

Так доказал, что тайпскрипт активно развивается и вполне себе состоятелен?

Потому что для массового кодинга выбора нет. И он транспилируется, а не включен в состав JS. Самое главное — тайпскрип умудряется делать свою магию даже на чистом JS, без аннотаций типов. Его магии сильно меньше, чем нужно для построения крупных проектов, но это лучше, чем ничего. И TS совершенно никак не поможет вашему проекту защититься от рукожопов, потому что если они захотят угробить ваш проект, то они это сделают, с TS или без оного, с React или с Vue — не важно.

А теперь объясни мне, почему из этого не следует вывод «они — рукожопы, и им нельзя поручать ответственные задания»?

Следует, чего же нет? Только он стоит рядом с выводом «писать свой фреймворк сложно»

Правильный ответ: фреймворки не нужны. Монолитные монстры должны уступить дорогу независимым функциям. Это вообще фундаментальная претензия к парадигме автора.

Сайт? У «сайта» нет динамического контента вообще, но он умудрился сделать этот сайт на PHP

Это вы про статические сайты не слышали

Это какие? На микросервисах и монге, небось?

byko3y ★★★★
() автор топика

Да у каждого первого свой неповторимый альтернативный взгляд на программирование. Читай всех подряд.

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

Если бы он банально рассказывал историю, то у меня не было бы вопросов. Проблема как раз в том, что он не «банально рассказывает историю», а делает мудацкие обобщения и конкретные указания

Ага, конкретное «указание» использовать что-то проверенное и надёжное(он ведь не говорит там про ларавел вообще), как посмел.

Потому что для массового кодинга выбора нет

Да плевать, тайпскрипт вполне себе доказал, что статическая проверка типов неплохо справляется.

И он транспилируется, а не включен в состав JS

Я знаю, он в статье рассказывает.

Правильный ответ: фреймворки не нужны

Бред, нужны, просто не всегда.

Это какие? На микросервисах и монге, небось?

Что? Это тот, который состоит из статических страниц.

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

А из моего опыта, был как раз свидетелем строительства велосипеда на PHP вместо использования фреймворка, печальное зрелище. Разработчик к второму-третьему проекту уже сам запутался в кодовой базе, в итоге после причесывания у нас получается тот самый «свой фреймворк», который нужно и в плане безопасности поддерживать, и дописывать уже готовую везде функциональность. Вряд ли у средней веб-студии достаточно ресурсов, времени и знаний чтобы этим заниматься, поэтому и Laravel/Yii во все поля

Так я же не спорю, здесь вопрос стоит ровно так: чей фреймворк окажется лучше — написанный нашими собственными макаками или макаками из сообщества? Готовые фреймворки пишут такие же люди, с двумя руками и ногами, и они тоже ошибаются. Если уровень макак внутри конторы низкий, то лучше брать сторонний код. Но может оказаться и так, что выбранный новомодный фреймворк сам написан рукожопами, и тогда намного лучше будет писать самим, даже если уровень кодеров в конторе весьма посредственный. Эффект «публичный фреймворк пишет много людей» не так уж и хорошо работает, если вспомнить, что это больше число людей не заботится по поводу требований вашего конкретно, и потому нужные вам фичи могут оказаться в плачевном состоянии, пока ненужны привлекают много внимания и хорошо поддерживаются. То есть, сам фреймворк с большим числом разрабов внутри не гомогенен.

Также напоминаю тезис выше: как правило, фреймворки общего назначения никому не нужны. В этом плане хороша Symfony, которую можно раздербанить по независимым кусочкам так, что это использование уже и не похоже на «фреймворк». Можно сказать, что Symfony — это фреймворк, который написан на библиотеках Symfony. То есть, как бы зонтичный бренд.

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

Да у каждого первого свой неповторимый альтернативный взгляд на программирование. Читай всех подряд

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

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

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

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

Ага, конкретное «указание» использовать что-то проверенное и надёжное(он ведь не говорит там про ларавел вообще), как посмел

Переходишь на другие страницы — а там «ехал ларавел через ларавел». Но на этой конкретной странице — да, нету упоминания. Но если посмотреть на статистику фреймворков:

https://insights.stackoverflow.com/survey/2021#most-popular-technologies-webf...

https://insights.stackoverflow.com/trends?tags=laravel,symfony,zend-framework...

то вообще-то топ 1 среди PHP фреймворков — это Laravel, значительно менее популярны Symfony и CodeIgniter, и дальше где-то в долях процентов уже идут остальные фреймворки. То есть, намек на популярный фреймворк — это достаточно недвусмысленный намек на ларавел.

Да плевать, тайпскрипт вполне себе доказал, что статическая проверка типов неплохо справляется

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

То есть, TS сам по себе не несет никакие преимущества проекту — TS хорош только при грамотном применении.

Брент же настаивает на том, что «давайте переписывать PHP», причем, он намекает именно на фундаментальную переработку — это в корне отличается от подхода TS, который вообще не трогает JS.

Правильный ответ: фреймворки не нужны

Бред, нужны, просто не всегда

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

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

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

Кстати, да. Нынче, со времен заката jQuery, до многих не может дойти, что уже можно писать фронт на голом JS, поскольку самые удачные функции из jQuery включены в состав браузера. Нет, они начинают искать «а что же теперь за библиотеку используют вместо jQuery? Наверное, React? Очень популярная штука, надо будет изучить». Очень тяжело манагеров с индусами приучить к мысли, что не иметь инструмент — удобнее, чем пытаться использовать какой-попало инструмент.

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

Переходишь на другие страницы — а там «ехал ларавел через ларавел»

И что? Речь про эту конкретную страницу.

То есть, намек на популярный фреймворк — это достаточно недвусмысленный намек на ларавел

Да вашу же дивизию, прекратите нести абсолютную чушь. Вы выдумали мирок, в котором ларавел — монстр, захвативший мир, и словосочетание «популярный фреймворк» в котором — «недвусмысленный намек на ларавел». Нет, ларавел — один из популярных фреймворков, точка.

Брент же настаивает на том, что «давайте переписывать PHP», причем, он намекает именно на фундаментальную переработку — это в корне отличается от подхода TS, который вообще не трогает JS.

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

В большинстве случае то, что нужно — это не фреймворки, а либы, вроде компонентов Symfony

Компоненты симфонии надо ещё подружить в одном проекте, на это уходит время, а значит и деньги. Только не все готовы платить, дешевле просто взять готовую симфонию (или собрать что-то типа сайлекса). Да и симфония предоставляет стандартный каркас, если ты знаешь симфонию, то сможешь относительно быстро приступить к поддержке проекта на ней. У подхода «возьмём готовую симфонию», конечно, есть недостатки, но есть и преимущества.

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

Переходишь на другие страницы — а там «ехал ларавел через ларавел»

И что? Речь про эту конкретную страницу

Про «эту конкретную страницу» я уже ответил, что там не всё так ровно. Почему фреймворк? Чем нонейм фреймворк отличается от фреймворка собственного производства? Что рукожопых макак, которые написали сторонний фреймворк, не нужно кормить?

Да вашу же дивизию, прекратите нести абсолютную чушь. Вы выдумали мирок, в котором ларавел — монстр, захвативший мир, и словосочетание «популярный фреймворк» в котором — «недвусмысленный намек на ларавел». Нет, ларавел — один из популярных фреймворков, точка

Давай за меня тебе ответит сам Брент:

https://stitcher.io/blog/php-in-2019:
«In general there are two major web application frameworks, and a few smaller ones: Symfony and Laravel. Sure there's also Zend, now called Laminas; Yii, Cake, Code Igniter etc. — but if you want to know what modern PHP development looks like, you're good with one of the first two.»

То же самое повторяется в https://stitcher.io/blog/php-in-2020

То есть, позиция автора: существует только два популярных фреймворка — ларавел и симфония. Всё. О чем я и говорил — причем, мне удалось это понять сразу после просмотра нескольких страничек его блога, но ты в упор отказываешься это видеть.

Он сначала высказывает мнение про несколько подходов, один из которых полная отмена проверки типов во время выполнение (что потребует изменить дизайн РНР), а потом говорит, что есть кое-что более простое, то, что сделал тайпскрипт

Хорошо, написано, дальше что? Это перестает делать его мудаком, который пытается беспорядочно натянуть попадающиеся под руку технологии на PHP? Тайпскрипт может работать вообще без транспиляции, как статический анализатор в IDE, который дальше IDE не выходит. Это он тоже упомянул, или все-таки нет? Где упомянуты линтеры? Это тоже статические анализаторы. Я могу долго придираться, там вся статья — одно сплошное домашнее задание школьника.

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

Ну тут я ни секунды не спорю: платить не все готовы, но по итогу всем придется — скупой платит дважды.

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

Чем нонейм фреймворк отличается от фреймворка собственного производства

Тем, что его разрабатывает большее число людей, которые часто перечитывают код друг друга. Тем, что его использует большое число людей.

https://stitcher.io/blog/php-in-2019:

То же самое повторяется в https://stitcher.io/blog/php-in-2020

In general there are two major web application frameworks, and a few smaller ones: Symfony and Laravel. Sure there’s also Zend, now called Laminas; Yii, Cake, Code Igniter etc. — but if you want to know what modern PHP development looks like, you’re good with one of the first two

Замечательно, и что с того? Есть основные фреймворки в индустрии, что дальше?

То есть, позиция автора: существует только два популярных фреймворка — ларавел и симфония. Всё. О чем я и говорил — причем, мне удалось это понять сразу после просмотра нескольких страничек его блога, но ты в упор отказываешься это видеть.

У человека есть мнение, и что с того? Я вам больше скажу, для запада это мнение ещё и верное, привет, yii. Он говорит «используйте фреймворк, подкреплённый комьюнити», а вы начинаете нести бред про рекламу ларавела.

Это перестает делать его мудаком, который пытается беспорядочно натянуть попадающиеся под руку технологии на PHP

А что он лично натягивает? Он приводит пример. Типы с дженериками в виде комментариев уже есть давно и без него, потом он же приводит пример трансляции в пхп.

Это он тоже упомянул, или все-таки нет

А он обязан?

Где упомянуты линтеры

Это тоже статические анализаторы

Ага, он и применяет более общее имя.

Я могу долго придираться

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

Ну тут я ни секунды не спорю: платить не все готовы, но по итогу всем придется — скупой платит дважды.

Дважды не значит больше.

fernandos ★★★
()
Последнее исправление: fernandos (всего исправлений: 1)

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

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

Тем, что его разрабатывает большее число людей, которые часто перечитывают код друг друга. Тем, что его использует большое число людей

Весь полный исходный код CodeIgniter весит где-то 30 тыс строк. Весь Yii с зависимостями — где-то 150-200 тыс. Код одного laravel/framework весит 70 тыс строк, при этом у него стенка зависимостей — мне затруднительно подсчитать их общий объем (может у кого-то уже установлены все они и он поможет мне посчитать), но я подозреваю, что это миллионы строк кода. То есть, это уже что-то масштаба ядра линукса, в котором отдельные баги висят по 12 лет, хотя сотни глаз просматривают сорцы. Та же самая проблема существует в мире node.js, и называется «проблема left-pad» в честь знаменательного дня, когда вся инфраструктура NPM рухнула из-за ошибки в одной из базовых библиотек. Как бы да, больше человек перечитывает код, но как бы и точек отказа на один-два порядка больше, чем в простеньких либах/фреймворках, что с лихвой съедает пользу от большего числа глаз и рук.

Замечательно, и что с того? Есть основные фреймворки в индустрии, что дальше?

А дальше всё. Два фреймворка. Вот и выбирай из них. По случайному совпадению, именно на них двоих и пишет Брент.

То есть, позиция автора: существует только два популярных фреймворка — ларавел и симфония. Всё. О чем я и говорил — причем, мне удалось это понять сразу после просмотра нескольких страничек его блога, но ты в упор отказываешься это видеть.

У человека есть мнение, и что с того? Я вам больше скажу, для запада это мнение ещё и верное, привет, yii. Он говорит «используйте фреймворк, подкреплённый комьюнити», а вы начинаете нести бред про рекламу ларавела

Ты сейчас неточно передал его цитату, он писал, дословно «Whatever framework you use, make sure it's backed by a large community». То есть, каким-то образом у него имеет значение размер сообщества, а не его качество. И я еще раз повторюсь, что вторая цитата подтверждает этот взгляд, так что это не вывод, сделанный по одному слову.

Это перестает делать его мудаком, который пытается беспорядочно натянуть попадающиеся под руку технологии на PHP

А что он лично натягивает? Он приводит пример. Типы с дженериками в виде комментариев уже есть давно и без него, потом он же приводит пример трансляции в пхп

Еще раз напоминаю мои исходные тезисы: Ресурсов альтернативных взглядов на программирование тред (комментарий)

Ты, точно как и он, снова и снова забываешь, зачем вообще всё это делается. Дженерики не нужны для дженериков, дженерики не нужны для проверки типов. Всё это нужно для статической проверки корректности программы, для которой аннотации типов не являются никаким краеугольным камнем. Ограничь конструкции в своем приложении до некоторого подмножества, легко проверяемого статически — и ты сможешь отловить большую часть ошибок без каких-либо аннотаций типов. И основная проблема в том, что именно Laravel и Symfony делают этот трюк практически нереальным, потому что переписавать такое количество кода под новый стиль никто не будет. И потому вопрос стоит в форме «как что-то поменять, ничего не меняя?». Ответ я уже дал — никак. Причем, то же мнение разделяют ведущие разрабы пыха как ЯП.

Более того, на самом деле и проверка простых типов в PHP фундаментально этих проблем не решила. Я подчеркиваю это, потому что наверняка ты уже готов был ответить «ну есть же подвиги в этом направлении, а ты говоришь, что ничего нельзя сделать». Да, имеющаяся проверка типов защищает от самых тупых ошибок, которые, в общем-то, и до этого прекрасно ловились тестами. Но от сложных ошибок типов и ошибок логики она не предохраняет совсем никак — а это наиболее проблематичные штуки, которые не так-то просто отловить даже тестами. На текущий момент эта проблема решается тупым заваливанием кода тестами в надежде. что прод не пройдет по неоттестированному сценарию. Или вообще никак не решается, и твои сайты сношают через светящую в инет админку без авторизации.

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

Где упомянуты линтеры
Это тоже статические анализаторы

Ага, он и применяет более общее имя

Нет, не применяет он никакого более общего имени. Для него статичная проверка — это проверка типов и только проверка типов, в чем ты можешь убедиться, поискав упоминания static в его статье — как правило, рядом с ним стоит какой-нибудь «type», «typing», или «generics».

Ну тут я ни секунды не спорю: платить не все готовы, но по итогу всем придется — скупой платит дважды.

Дважды не значит больше

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

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

Ты хочешь коллекцию правильных решений? Серебряных пуль не бывает, для каждой конкретной задачи нужно заново выбирать оптимальное

В том числе об этом была ссылка https://phpthewrongway.com/

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

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

Весь полный исходный код CodeIgniter весит где-то 30 тыс строк. Весь Yii с зависимостями — где-то 150-200 тыс. Код одного laravel/framework весит 70 тыс строк, при этом у него стенка зависимостей — мне затруднительно подсчитать их общий объем (может у кого-то уже установлены все они и он поможет мне посчитать), но я подозреваю, что это миллионы строк кода

А давайте узнаем, как дела обстоят на самом деле. Кодинтежер не сравниваю, он куций.

Создадим базовый проект ларавела и yii2, тот, который они предлагают с самого начала.

Yii2 --- 68 мегабайт весь проект, 68 мегабайт --- вендор композера, 1690543(469928) строк кода.

Laravel --- 53 мегабайт весь проект, 53 мегабайт --- вендор композера, 574064 строк кода.

Ой, как же так вышло? Не миллион. У ларавела, а вот у yii более полутора миллиона.

А дальше всё. Два фреймворка. Вот и выбирай из них. По случайному совпадению, именно на них двоих и пишет Брент.

И плевать, что есть лишь два популярных фреймворка на западе, да, это Брент виноват.

То есть, каким-то образом у него имеет значение размер сообщества, а не его качество

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

И основная проблема в том, что именно Laravel и Symfony делают этот трюк практически нереальным, потому что переписавать такое количество кода под новый стиль никто не будет

Да нет, как раньше кардинально меняли вордпресс (для поддержки 7-й версии), так же изменять и фреймворки.

Нет, не применяет он никакого более общего имени. Для него статичная проверка — это проверка типов и только проверка типов, в чем ты можешь убедиться, поискав упоминания static в его статье — как правило, рядом с ним стоит какой-нибудь «type», «typing», или «generics».

Потому что эта статья конкретно про типы.

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

В обоих случаях я считал только PHP файлы (find . -type f -not -name «*.php» | xargs rm). Прямое сравнение, однако, недопустимо, поскольку в Yii2 включены тесты и зависимости ставятся с тестами, а в laravel тестов всего-лишь несколько килобайт.

Laravel, за вычетом 11.5 МБ текстов Faker и 3.5 МБ текстов Carbon — 37 MБ, 8 МБ фреймворка и 29 МБ зависимостей, из которых 3.2 Мб phpunit.
Yii2, за вычетом собственных тестов (4.5 МБ) и тестов из зависимостей (1.5 МБ) — 18 МБ, 6 МБ фреймворк и 12 МБ зависимости, из который 5.8 — это php-cs-fixer и phpunit.
CodeIgniter, за вычетом 11.5 МБ текстов Faker — 16 МБ, 4.5 МБ фреймворка и 11.5 МБ зависимостей, из которых 4 МБ phpunit.

То есть, да, не миллион — полмиллиона. Но и да, у Yii2 и CodeIgniter тоже есть ориентация на американский рыночек (переусложненных продуктов).

И плевать, что есть лишь два популярных фреймворка на западе, да, это Брент виноват

Мне тоже всё равно, два их или десять на западе. Я писал про его конкретные высказывания сомнительной ценности по поводу «я здесь больно ударился — не делайте так больше, пользуйтесь фреймворками с большим сообществом». И я отвечаю ему, что он совершенно не понял, из-за чего произошла ошибка, и сделал ошибочный вывод. Странно при этом, что он не сделал вывод «PHP не нужно», который на самом деле ближе к реальности. И эта неспособность сделать вывод повторно проявилась в его предложении обобщений для PHP.

Конечно, есть второй сценарий: это что на самом деле Брент всё прекрасно понимает, но рисует себе имидж, вместо суровой прагматичной оценки предпочитая популистские фразы «я делаю PHP лучше» и «пыхеры всех стран — объединяйтесь (прочитав мою книжку)».

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

Объективно количество людей в сообществе можно измерить, но это абсолютно бессмысленная оценка, поскольку минимум 95% людей в этом сообществе будут бесполезны. Качество сообщества можно оценить субъективно, и эта оценка будет намного полезнее, чем любая объективная оценка.

Да нет, как раньше кардинально меняли вордпресс (для поддержки 7-й версии), так же изменять и фреймворки

В каком месте переписали? Аннотаций типов как не было, так и нет, замыкания так же реализованы на простых объектах, генераторов нет.

Потому что эта статья конкретно про типы

Ну и ты можешь дать ссылку на какую-нибудь другую статью, где это были бы не типы? Единственное, что я нашел:

https://stitcher.io/blog/php-8-before-and-after

«I don't have to bother anymore writing and managing method names as strings: your IDE can't autocomplete them, there's no static analysis on typos and method renaming doesn't work»

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

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

CodeIgniter

Я уже говорил, его просто так никто не использует, он ещё разжиреет.

Yii2

Ага, ещё будет подключаться движок шаблонов.

То есть, да, не миллион — полмиллиона

И где-то четверть — комментарии.

Я писал про его конкретные высказывания сомнительной ценности по поводу «я здесь больно ударился — не делайте так больше, пользуйтесь фреймворками с большим сообществом». И я отвечаю ему, что он совершенно не понял, из-за чего произошла ошибка, и сделал ошибочный вывод.

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

Объективно количество людей в сообществе можно измерить, но это абсолютно бессмысленная оценка, поскольку минимум 95% людей в этом сообществе будут бесполезны. Качество сообщества можно оценить субъективно, и эта оценка будет намного полезнее, чем любая объективная оценка.

Нет, нельзя. Мы говорим даже не про языки, а про фреймворки.

В каком месте переписали

Можете посмотреть на их гите.

Аннотаций типов как не было, так и нет

Есть в пхпдок.

замыкания так же реализованы на простых объектах, генераторов

Фичи 5-й версии, видимо, они им не нужны.

Ну и ты можешь дать ссылку на какую-нибудь другую статью, где это были бы не типы?

Обсуждая эту конкретную статью?

https://www.stitcher.io/blog/php-in-2019

https://www.stitcher.io/blog/a-project-at-spatie

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

Yii2

Ага, ещё будет подключаться движок шаблонов

Дохера чего будет подключаться — ты не запихнешь во фреймворк всего, А всё и не нужно. Это типовой американский подход — чем больше фич, тем лучше. Не «чем больше фич ты можешь подключить/добавить/доработать» — я подчеркиваю. Всё должно быть из коробки, с минимальной возможностью конфигурации, даже если оно наспех примотано синей изолентой и еле держится. Технический долг улетает в небеса, но расчет идет на то, что либо бизнес взлетит и с лихвой окупит многократно выросшие счета на уплату этого долга, либо накроется медным тазом и тогда уже про роль ПО никто не вспомнит.

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

Сообщество, может быть, и хотело бы сделать инструмент для всех задача на свете, но убогость метапрограммирования в PHP не позволяет, грубо говоря, взять из либы 1000 строчек так, что они будут генерировать 100 строчек оптимального кода точно под твою задачу в соответствии с параметрами, которые ты задал. А потому либо генераторы крудов, которые будут допилены руками и копипастой, либо формирование параметров обработки крудов в рантайме под каждый запрос. То есть, либо ручная оптимизация, либо готовый универсальный медленный код — как во фреймворке.

То есть, да, не миллион — полмиллиона

И где-то четверть — комментарии

Больше — я брал из расчета, что половина строк являются комментариями. С комментами там лям.

Я писал про его конкретные высказывания сомнительной ценности по поводу «я здесь больно ударился — не делайте так больше, пользуйтесь фреймворками с большим сообществом». И я отвечаю ему, что он совершенно не понял, из-за чего произошла ошибка, и сделал ошибочный вывод

Я уже говорил, что это только пример того, с чем может столкнуться разработчик, который пишет свой фреймворк

Меня вообще не колышет вопрос абстрактного разработчика, захотевшего написать абстрактный фреймворк. Я говорю про конкретного человека, про его отношение к коду и своей работе. «Упало — да и хрен с ней, как-нибудь замнем. Давайте в следующий раз сделаем так, чтобы нельзя было стрелки перевести на нас». Это подход эффективного манагера, но ты его преподносишь как супер-пупер архитектора, а я тебе и показываю, что это прохиндей, который профессионально занят пусканием пыли в глаза, и наняли его люди с таким же мировоззрением, для которых такое поведение — норма, а вот для меня это дикость и очень режет глаз. Такие люди могут быть полезными для установления связей между людьми — чем он, собственно, в интернете и занимается. Но задачи ответственный ему давать нельзя, потому что он их похерит, и будет долго и красиво рассказывать о том, почему иначе получиться не могло, про объективные причины, про трудности на пути, про ограничения технологий — всё что угодно, кроме взятия вины на себя.

Нет, нельзя. Мы говорим даже не про языки, а про фреймворки

Тебе нельзя, мне можно — вопросов нет.

В каком месте переписали

Можете посмотреть на их гите

Если не считать вот этого
https://github.com/WordPress/WordPress/commit/ef87172270525aef03fc7b9a210abbb...
то я никаких «переписываний» не нахожу. Например, я взял wp-admin/nav-menus.php сейчас
https://raw.githubusercontent.com/WordPress/WordPress/7829821c62d1bf902859f0c...
и он же 8 лет назад:
https://raw.githubusercontent.com/WordPress/WordPress/72d4b140fb306d5f5c2e741...
Примерно на 80% код совпадает — это за 8 лет.

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

https://www.stitcher.io/blog/a-project-at-spatie

Classes should be small, 50 lines of code should be the maximum
Methods should also be small and easy to reason about
We prefer clear names over short and cryptic names

I've made a little tool in the past which I use to generate «heat maps» of the codebase. It will take all code in a folder, and generate an image by overlaying the code structure on top of it

Капец, зачем ты мне это дал. Это 1000% манагер. Не «класс должен выполнять только одну функцию», а «класс должен быть не более 50 строк». На митингах, когда кто-то в тиме написал класс на 70 строк, он будет долго публично лить грязь на провинившегося, мол «кто так пишет, ты домашнюю работу делаешь или коммерческий проект, как тебе не стыдно».

Однострочные методы — это убийцы читаемости, но его это не волнует, потому что читаемость он меряет картиночкой с плотностью кода, рисуемой своей самописной тулзой, которую использует вместо мозга и глаз. Графики, посиделочки в курилке, давайте еще раз нарисуем план архитектуры, следующее плановое совещание через два часа — не опаздывайте, я новых картиночек вам нарисую. Даже в средненькой уважающей себя галере его через пару месяцев выгонят, потому что код так написать почему-то не получается. Зато можно пойти в интернет, создать свой бложик, поделиться опытом, написать книжечку, рассказать о том, как ты развиваешь весь PHP мира.

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

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

Дохера чего будет подключаться — ты не запихнешь во фреймворк всего

Я запихну только необходимое. А шаблонизатор точно нужен.

Больше — я брал из расчета, что половина строк являются комментариями. С комментами там лям.

Что конкретно вы смотрите? Я взял example-app ларавела, там 575826 всего, это меряет onefetch.

Если не считать вот этого

Вы действительно считаете, что представление — лучший метод смотреть развитие.

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

Я запихну только необходимое. А шаблонизатор точно нужен

Кому-то нужен, кому-то не нужен — например, страницы выдают сложную динамику при простой разметке. В пределе это называется «REST API».

Что конкретно вы смотрите? Я взял example-app ларавела, там 575826 всего, это меряет onefetch

Это доказывает, что моя оценка корректна. Вот откуда у тебя полтора миллиона в Yii2 — это хороший вопрос.

Вы действительно считаете, что представление — лучший метод смотреть развитие

Так не я выдвигал тезис про переписывание — я как раз этого переписывания не вижу.

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

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

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

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

Кому-то нужен, кому-то не нужен — например, страницы выдают сложную динамику при простой разметке

РНР, конечно, является препроцессором гипертекста, но не до такой степени.

Это доказывает, что моя оценка корректна

Там полмиллиона с комментариями, товарищ.

Вот откуда у тебя полтора миллиона в Yii2 — это хороший вопрос

Это их basic template, или как его, дьявола, в скобке я привёл количество строк когда удалил какую-то директорию, тесты, ЕМНИП.

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