подавляющее большинство его до конца не понимает. Где-то год назад у меня было пара знакомых функциональщиков. которые во весь голос кричали что ООП говно. В итоге я даже начал сомневаться, но месяц холиваров привели нас к консенсусу что правильное ООП ничуть не хуже) Но большинство делают как придется)
> Но на деле entity system можно объяснить за десять минут
Можно. Но у ECS все же своя сфера применения. Знать о этом подходе пожалуй полезно, но я думаю сначала таки перевести ту статью по MVC которую я скидывал (там где rethinking MVC от 2004-ого года вроде).
Дмитрий Ким: ну так не делайте лишних проверок. Если вы работаете с каким-то массивом - просто задайте значения по умолчанию через какой array_replace и больше не беспокойтесь.
copal: ну так это же здорово) стремление к упрощению, декомпозиция.
Я к сожалению последние месяца 3-4 практически не занимаюсь фронтэндом, но мои ребята активно юзают и rx.js и rx.java и т.д. при работе с I/O. И вроде как все довольны.
spotifi: То что вокруг D нет такого хайпа - это еще не говорит о том что он не взлетел. Не знаю откуда вы такую информацию берете. Вполне себе неплохой язык который вполне себе может занять нишу. А с учетом того что стандартная библиотека теперь не завязана на сборщике - вполне себе достойный кандидат на нишу между rust и go.
Что до Go - у этого языка весьма специфическая сфера применения - это в основном web, распределенные системы и все что связано с эффективной работой с I/O. А вот для вычислений пока круче Си ничего нет, увы. Во всяком случае пока-что.
Так что "искусственность" вызвана лишь тем, что за последние 40 лет просто ничего лучше не придумали. Вот сегодня у нас есть альтернатива, причем прекрасно совместимая с Си в плане модели работы с памятью что делает реюз существующего кода простым. лет 5 назад альтернативы вообще небыло.
copal: ну JS хоть и считается языком с сильной динамической типизацией... до python ему далеко в этом плане.
Просто представь..... у тебя полностью динамический язык в котором ты можешь творить в принципе все что тебе вздумается, он тебя практически не ограничивает... И при этом ты не можешь менять тип переменных или же должен явно кастить типы при операциях.
print ("The answer is: " + 42) # Ошибка, нужно явно кастить к строке
ну а статическая информация о типах - python с версии 3.5 поддерживает тайп хинтинг, который по сути работает так же как в typescript - не влияет на рантайм. Тупо для статических анализаторов.
spotifi я все же с вами не соглашусь по поводу того что первый язык должен быть со статической типизацией. Если исходить из вопроса "понимания концепции типов" то лучше уже какой язык с сильной динамической типизацией, где нет неявных кастов типов на уровне рантайма.
Так что в этом ключе Python как раз таки подходит. Даже не смотря на то что он очень динамический.
Си в этом плане больше с памятью научит работать.
По Go тоже непонятно. Там не "без методов но с интерфейсами", там есть методы. Просто нет классов.
copal: в целом эту проблему рашеют модули. У нас нет состояния, а стало быть нет необходимости в инкапсуляции данных. Управлять же зависимостями вполне можно при помощи модулей. Абсракция будет достигаться "подсовыванием" нужных модулей в зависимости от конфигурации.
В целом повторюсь - я не агитирую за отказ от ООП, как по мне это наиболее приемлимый способ делать дела эффективно. Просто идеи функционального программирования хорошо проэцируются на ООП (как никак монады весьма неплохо коррелируются с объектами). И в целом я считаю что совмещение этих подходов дает максимально безопасный и удобный код.
diamond: если код проекта завязан на этом фреймворке. Современные решения вроде symfony или zend используют invertion of control для того что бы снизить связанность. Да и мы же не про то что без рефакторинга и тестов код рано или поздно станет неподдерживаемым?
Павел Волынцев: да я сам их слушаю, тут пожалуй плохая аналогия вышла)
unfapable: нет, я предлагаю вам вместо массивов айдишников хранить мэпу айдишников. Тогда вместо поиска элемента в массиве за сложность N, где N это количество элементов массива которые нужно обойти, у вас будет поиск ключа за единичное время (потому что по хэшу).
по поводу "бесполезности" кастылей - я это к тому что вполне себе честная многопроцессорность достигается через proc_open который в php из коробки есть. И не нужно городить этого трэшачка. Но опять же многопроцессорность штука дорогая, как собственно и треды.
многопоточность в PHP существует (pthreads экстеншен), но для этой задачи оно не нужно. А то что по ссылке - это бесполезные кастыли.
Для справки, PHP может из коробки неблокируемые вызовы, то есть мы не будем дожидаться пока завершится обработка запроса а просто будем делать следующий. Ну мол как в javascript.
rogoff13: твиттер к примеру вообще не отдает email, принципиально. В фэйсбуке (не знаю как сейчас) тоже можно было запретить отдавать email и тогда возвращаться будет фэйковый.
Если у вас нет email-а - просто регистрируете новый аккаунт. В профиле пользователя просто будет возможность "привязать" аккаунт соц сети, там можно запоминать user id, который возвращают все.
titronfan вообще-то это весьма простая капча, и писать нейронные сети на PHP более чем можно. Другое дело что если кому-то мешают капчи гугла - значит кто-то делает что-то плохое.
Но вот мне ссылка пригодится, спасибо.