К тому что из коробки написано то что не из коробки, следовательно все плюсы теряются. Вместо того чтобы допилить то что более портабельно, ставить system-wide костыли.
объекты с отношением belongs_to теперь по умолчанию должны иметь родителя, иначе будет exception
Вот это очень спорное решение. Интересно has_many будет также работать?
MS к сожалению не любит слово совместимость. Добавят какие то дополнительные "плюшки" к плагинам VS Code которых в Atom нет и прощай совместимость. Все перепрыгивают на VS Code, M$ делают его закрытым. Вуаля, типичный microsoft. Это в случае если продукт станет популярным.
А они весь интерфейс писали или использовали какую то часть кодовой базы Atom? поиску по файлам выглядит идентично, дерево тоже. Я не думаю что они с нуля это писали, можете как то опровергнуть?
Atom/Sublime как раз таки в моем случае решает проблему скорости, тормознутости и раздутия интерфейса. Всего этого из коробки там просто нет. Ставятся все нужные плагины очень очень быстро. Только не говорите мне что вы не настраиваете Jetbrains idename совсем. Я пользовался какое то время ими, они круты, но скорость работы интерфейса удручает, а настраивать точно приходилось.
Поэтому и нужно давать отдельно инструкцию по "быстрому" запуску без всех этих идешек.
Ну и ответьте мне, с какого момента ссылаться на blink а не webkit? когда они добавят фичу X? по мне так когда форк произошел тогда и надо ссылаться на конкретный движок, а не плодить невежество.
Программа от апполона писалась специально под апполон и специально под одну конкретную задачу. Эта игра писалась специально под конкретное окружение и больше ничего не поддерживает. Написать сегодня 2D игру под windows проще чем раньше под msdos, достаточно взять например SDL и вы приблизительно за тоже время что и автор игры напишете порт, это в случае если бы у вас было полное ТЗ на игру, при этом вы с нулевым оверхедом сможете себе позволить графику получше. Стек у вас получился бы больше, но он стал бы более "общим", api стаал бы общим, вы не затачиваете свою игру под узкое, конкретное окружение. И больше авторов смогло бы работать над игрой, потому что использовалась популярная известная библиотека, а не какой то узкий самописный код с собственными решениями.
Раздутие стэка? да. Зато проще портировать на те платформы где этот стэк присутствует (в моем примере C + SDL)
Однако портирование игры с одной платформы на другую ВСЕГДА было сложной задачей. Взять хотя бы какой нибудь допустим apple ||, как просто было бы вам портировать DOS игру на подобный компьютер? думаю это было бы архисложной задачей, ничуть не проще чем написание эмулятора. Помимо этого у JS совершенно другая парадигма программирования (асинхронные события) которой в MSDOS нет, там код однопоточен и синхронен (образно).
Выводы: раздутие стэка увеличивает скорость разработки, позволяет запустить нечто на нескольких платформах обхватив большую аудиторию, зачастую позволяет привлекать новых программистов в проект многократно быстрее чем если писать собственное решение.
Портирование с одного "domain" на другой, как было сложным так таким и осталось. Если не стало проще.
Шел 2016 год, мы писали расширения для php на PHPCPP/C/C++ и похоже это не перевод. https://packagist.org/search/?q=icu
Не уверен что по ссылке выше есть именно нужный вам компонент, но в случае если вы хотите написать какой то класс/пакет которым будет пользоваться современный разработчик то вам стоит узнать о composer https://getcomposer.org/ (судя по php расширению вы о нем знаете)
сегодня вам понадобился стек чтобы запустить эту игру где она не была предназначена запускаться. Игра запускалась только на определенной архитектуре под определенной ос. Игра была просто заточена на очень конкретное окружение.
Теперь, вы запустили ее в браузере, технически позволив запустить игру на целой куче платформ, используя технологический стек с открытыми стандартами, а значит завтра разработчик собственного браузера тоже сможет запустить игру у себя.
Теперь вопрос, что быстрее, написать один раз эмулятор под DOS игры, или переписать тысячу игр? Сегодня эта игра должна работать не под DOS, а под windows 7, 8, 10, android, ios, при этом желательно не писать каждую версию с нуля. Потому и раздувается стэк, потому что это сокращает время разработки.
Чтобы играть без акселерации, на мышке нужны клавиши понижения скорости. Иначе с автомата вы будете попадать, а из какой нибудь снайперской винтовки будете вечно мазать, потому что там нужна скорость меньше.
Вы действительно уверены что это не то?
http://symfony.com/blog/new-in-symfony-2-6-farewell-to-icu-component
вместо того чтобы тащить системную библиотеку, проще притащить php библиотеку per project.
Поэтому и нужно давать отдельно инструкцию по "быстрому" запуску без всех этих идешек.
Раздутие стэка? да. Зато проще портировать на те платформы где этот стэк присутствует (в моем примере C + SDL)
Однако портирование игры с одной платформы на другую ВСЕГДА было сложной задачей. Взять хотя бы какой нибудь допустим apple ||, как просто было бы вам портировать DOS игру на подобный компьютер? думаю это было бы архисложной задачей, ничуть не проще чем написание эмулятора. Помимо этого у JS совершенно другая парадигма программирования (асинхронные события) которой в MSDOS нет, там код однопоточен и синхронен (образно).
Выводы: раздутие стэка увеличивает скорость разработки, позволяет запустить нечто на нескольких платформах обхватив большую аудиторию, зачастую позволяет привлекать новых программистов в проект многократно быстрее чем если писать собственное решение.
Портирование с одного "domain" на другой, как было сложным так таким и осталось. Если не стало проще.
https://packagist.org/search/?q=icu
Не уверен что по ссылке выше есть именно нужный вам компонент, но в случае если вы хотите написать какой то класс/пакет которым будет пользоваться современный разработчик то вам стоит узнать о composer https://getcomposer.org/ (судя по php расширению вы о нем знаете)
Теперь, вы запустили ее в браузере, технически позволив запустить игру на целой куче платформ, используя технологический стек с открытыми стандартами, а значит завтра разработчик собственного браузера тоже сможет запустить игру у себя.
Теперь вопрос, что быстрее, написать один раз эмулятор под DOS игры, или переписать тысячу игр? Сегодня эта игра должна работать не под DOS, а под windows 7, 8, 10, android, ios, при этом желательно не писать каждую версию с нуля. Потому и раздувается стэк, потому что это сокращает время разработки.