Согласен, товарищ мог перепутать.
В отличие от pick, Moveable вообще не имеет общепринятого названия, т.к. подход мало распространён. Я бы предложил перевести его как «переносимый объект».
В фреймворк заложено такое количество интересных идей, что одной статьёй вряд ли можно будет просто их адекватно перечислить.
Только что написал статью, посвящённую идеологии управления ресурсов в U++. За счёт неё удаётся побеждать всю или почти всю головную боль с утечками памяти.
Привет программерам U++! )
Pick- называю более «привычным» термином «разрушающее копирование» в 4 пункте, попутно разбирая семантику этого действия в нашем контексте. В одной из предыдущих статей меня поправили, что, пользуясь необщепринятыми понятиями, я путаю аудиторию. Тогда я перевёл всё на стандартный язык.
В самом начале статьи я написал, что внутри каких-то сложных объектов с определённой спецификой, наверное, создание аллокатора с GC может иметь смысл. Мы с Вами говорим немного о разных вещах: я за то, чтобы внутри специфических объектов было то, что им нужно. И я за то, чтобы это не просачивалось наружу. Потому что снаружи, с моей точки зрения, «ручные» GC вредны. Почему — я написал.
Отсюда, ваш подход — вполне возможно, хорош внутри вашего специфического объекта (максимум — пула объектов). Что касается программ «с птичьего полёта» — то подход другой.
С поправкой согласен.
Хочу только заметить, что здесь важнее само соглашение. Иначе, Вы прекрасно сами понимаете: есть 100500 способов обойти любую константность и прочее, сделав всё что угодно.
Сюда же сверхбыстрые строки и контейнеры, нативная поддержка json, xml и прочего.
А так же, моя библиотека сверхбезопасной многопоточности на sequential processes.
Извините, не удержался.)
U++ — библиотека на любителя, но крайне гибкая и мощная, если научиться пользоваться.
В остальном — просто не хочу оффтопить. И гуй, и поддержка всего от быстрых контейнеров до SSL, там не просто есть, а очень сильно есть. )
Нынешней властью — вряд ли. А то вдруг может оказаться, что академик был вовсе не так рукопожатен, как принято думать. И — свят-свят-свят — сотрудничал с кровавым режимом, как и Александр Исаич. ))
Мне очень нравится: о том, что наших физиков не выпускали на конференции в США, наши «правозащитники» воют на всех углах. А когда американцы своего физика не выпускают в СССР — это нормально, это в порядке вещей, ведь государственная безопасность важнее.
Я бы добавил, что данный подход — не панацея ещё и потому, что противоречит важнейшему принципу Киркхгоффса.
В нашем случае, оно сводится к тому, что, получив (выкрав) исходники, злоумышленник узнает алгоритм генерации «соли» и сведёт задачу к достаточно простой вычислительной задаче: GPU-перебору словарь + известная соль.
Программы всё больше и больше уходят в веб, то есть в браузерный яваскрипт. А значит будущее за новыми подходами, которые смогут, наконец, подружить браузер и скриптовую многопоточность.
Первый шаг сделан: яваскрипт постепенно превращается из интерпретируемого языка в компилируемый.
Дальше — вопрос логики и новых редакций стандартов.
Вот где действительно развернётся будущая битва за производительность.
И здесь бы, пожалуй, помог отказ от классической синхронизации потоков с использованием мьютексов и прочих семафоров. Для браузерного программирования более адекватным будет параллельное программирование через обмен сообщениями между объектами, работающими в разных потоках. Это, конечно, создаёт не только возможности, но и сопутствующие проблемы.
С одной стороны, де-факто отсутствие разделяемой памяти упростит расширение на сколь угодно большое количество ядер. С другой стороны, появляется масса проблем, связанных как с самим подходом (задержки и прочее), так и увязкой этого с визуализацией DOM. Похоже, это дело браузеров будущего.
Причём тут конспирология? Кибер-подразделения есть в армиях всех развитых стран.
Очевидно, что они не тетрис там пишут.
Вирус — вполне очевидное оружие любой современной армии.
Представление ленты переписки с группировкой по контактам было мною предложено ещё в 2009 году — как на общих стартап-сессиях, так и персонально, например, Яндексу. Рад, что идея постепенно получает своё воплощение.
Вы как раз озвучили одну из альтернатив.)
С моей точки зрения, в следующей статье было бы неплохо как раз обсудить этот новый язык разметки, который «рендерится» в CSS/HTML.
Уважаемый автор! С моей точки зрения, оценка CSS/HTML представления страниц — есть величина не только субъективная, но и сравнительная.
И теперь мой к Вам вопрос: с чем Вы предлагаете сравнивать? Какие у нас есть альтернативы, по сравнению с которыми мы могли бы назвать данные технологии сравнительно бесполезными, либо сравнительно полезными?
К примеру, ВАЗ 2106 следует оценивать не только по неким характеристикам, но и сравнительно. Когда у меня не было никакой машины, и ВАЗ решал мне массу проблем (разумеется, создавая массу новых). Но при этом всём, был сравнительно полезным. Когда у меня появилась иномарка, те же задачи стали решаться с гораздо меньшим количеством проблем. ВАЗ 2106 стал сравнительно бесполезен и был продан.
Мы же взрослые люди, уважаемый автор. Давайте исходить из реальности.
Вы считаете что HTML/CSS — плохи?
Предлагайте альтернативы. Давайте их обсуждать.
Причём обсуждать в реальном комплексе проблем, связанных с необходимостью менять инфраструктуру крупными корпорациями и т.д.
В отличие от pick, Moveable вообще не имеет общепринятого названия, т.к. подход мало распространён. Я бы предложил перевести его как «переносимый объект».
Только что написал статью, посвящённую идеологии управления ресурсов в U++. За счёт неё удаётся побеждать всю или почти всю головную боль с утечками памяти.
Pick- называю более «привычным» термином «разрушающее копирование» в 4 пункте, попутно разбирая семантику этого действия в нашем контексте. В одной из предыдущих статей меня поправили, что, пользуясь необщепринятыми понятиями, я путаю аудиторию. Тогда я перевёл всё на стандартный язык.
Отсюда, ваш подход — вполне возможно, хорош внутри вашего специфического объекта (максимум — пула объектов). Что касается программ «с птичьего полёта» — то подход другой.
Хочу только заметить, что здесь важнее само соглашение. Иначе, Вы прекрасно сами понимаете: есть 100500 способов обойти любую константность и прочее, сделав всё что угодно.
А так же, моя библиотека сверхбезопасной многопоточности на sequential processes.
Извините, не удержался.)
В остальном — просто не хочу оффтопить. И гуй, и поддержка всего от быстрых контейнеров до SSL, там не просто есть, а очень сильно есть. )
В нашем случае, оно сводится к тому, что, получив (выкрав) исходники, злоумышленник узнает алгоритм генерации «соли» и сведёт задачу к достаточно простой вычислительной задаче: GPU-перебору словарь + известная соль.
Первый шаг сделан: яваскрипт постепенно превращается из интерпретируемого языка в компилируемый.
Дальше — вопрос логики и новых редакций стандартов.
Вот где действительно развернётся будущая битва за производительность.
И здесь бы, пожалуй, помог отказ от классической синхронизации потоков с использованием мьютексов и прочих семафоров. Для браузерного программирования более адекватным будет параллельное программирование через обмен сообщениями между объектами, работающими в разных потоках. Это, конечно, создаёт не только возможности, но и сопутствующие проблемы.
С одной стороны, де-факто отсутствие разделяемой памяти упростит расширение на сколь угодно большое количество ядер. С другой стороны, появляется масса проблем, связанных как с самим подходом (задержки и прочее), так и увязкой этого с визуализацией DOM. Похоже, это дело браузеров будущего.
Очевидно, что они не тетрис там пишут.
Вирус — вполне очевидное оружие любой современной армии.
С моей точки зрения, в следующей статье было бы неплохо как раз обсудить этот новый язык разметки, который «рендерится» в CSS/HTML.
И теперь мой к Вам вопрос: с чем Вы предлагаете сравнивать? Какие у нас есть альтернативы, по сравнению с которыми мы могли бы назвать данные технологии сравнительно бесполезными, либо сравнительно полезными?
К примеру, ВАЗ 2106 следует оценивать не только по неким характеристикам, но и сравнительно. Когда у меня не было никакой машины, и ВАЗ решал мне массу проблем (разумеется, создавая массу новых). Но при этом всём, был сравнительно полезным. Когда у меня появилась иномарка, те же задачи стали решаться с гораздо меньшим количеством проблем. ВАЗ 2106 стал сравнительно бесполезен и был продан.
Мы же взрослые люди, уважаемый автор. Давайте исходить из реальности.
Вы считаете что HTML/CSS — плохи?
Предлагайте альтернативы. Давайте их обсуждать.
Причём обсуждать в реальном комплексе проблем, связанных с необходимостью менять инфраструктуру крупными корпорациями и т.д.