для российских разработчиков вообще может сильно упасть интерес дальше развивать продукты в этом классе,
С другой стороны: раз за разом(разные разработчики, разные продукты) оплачивать один и тот же функционал за счет госбюджета - тоже выглядит не очень хорошо.
надо ради этого мессенджера обеспечить доступом в Интернет, потому что иметь свой "закрытый" мессенджер для рабочих коммуникаций - нельзя
Из занудства: или потребовать от производителя возможности устанавливать тот же месседжер, но в режиме "self-hosted"/закрытого контура. Никто же, вроде, требует, чтобы это именно одна инсталляция на всю страну была.
То что "многофункциональный сервис обмена информацией" == "Max" -- это отдельное распоряжение.
Насчет которого могут и передумать, если совсем халтурить. А желающие стать заменой - будут еще и всячески способствовать, чтобы это 'передумать' состоялось.
"А ты, друг мой горемычный, собственно, где эту поделку купил? Покажи квитанцию!"
Желание производителей оказываться от своей же продукции, но проданной по 'серым' схемам немного задалбливает. Продукция ваша? Как "подделка"? А доказать можете что именно подделка? Ах нет... Значит - ваша, извольте обслуживать, даже если она до меня дошла через десяток промежуточных рук и три раза мир обогнула. А если маршрут вам не нравится и его не должно быть - разбирайтесь как-нибудь сами со своими продавцами, а не с пользовтелем.
Правильно, это должна делать система сборки и, если возможно, рантайма. Скомпилировать исходник с константами - это доли секунды, так-то. А вот сделать так, чтобы они реально работать начали и это было быстро - ну, тут все систематически грустно.
Как раз все эти public private protected это попытка в ту сторону...
Эти - просто про чистоту кода.
И потом что что бы программисты системы ни написали, менеджер (которому тоже права редактирования кода выдали) - все равно может библиотечными функциями работы с файлами пользоваться - на них же все публичные.
Я про что-то вроде этого (условный код, очень грубо)
sandbox
config
default policy deny
allow import reports.* orders.*
allow execution "список функций"
import "какой-нибудь модуль с утилитными функциями"
code
include "Тут путь до модуля, который редактирует условный менеджер"
После чего этот самый менеджер в своем коде может модулями работы с заказами пользоваться, с отчетами - и больше ничем. А если попробует - его код просто не скомпилируется.
А если работает только с тем, что выдали - скомпилируется и успешно в очередную версию приложения автоматикой поставится.
После чего постепенно вообще все становится написанным на таком вот "менеджер мог сам расписать". Одновременно двигаясь в сторону, что на практике не может и не захочет.
Вообще, современным языкам, похоже, не хватает внятно оформленной концепции "единица компиляции/интерпретации с ограниченными правами". Чтобы эти самые менеджеры/пользователи могли сразу на целевом языке писать, но не могли написать лишнего.
Она не поможет, если код уже опубликован в распространяющей платформе, заверен разными подписями, проверен на 'не злит ли он антивирусы' и так далее. Если его менять - это же все заново проделывать надо. А конфиг - можно быстренько подправить и тот же самый бинарник его без всей этой бюрократии съест.
Это эквивалентно. Просто у вас "генератор C++ из... <что там у нас есть>" встроен невидимым для вас образом в компилятор (и эту часть тоже кем-то написана, "желательно без ошибок")
жутком франкенштейне который в основном выдумали люди не имеющие к программированию никакого отношения.
Да нет, выдумывают как раз люди, к программированию отношение имеющие. Только ползучим образом. "А давайте сделаем так, что вот сюда можно не просто значение вписать, а шаблон/формулу и будем его интерпретировать." - это так программисты мыслят. И "загоним логику в XML, превратив его в текст программы" - тоже. Тут, правда, отдельным пунктом идет "визуальное представление логики", которое тоже все портит. Почему то считается, что "нормальному пользователю" легче понять эту лапшу коннекторов, чем просто текст.
которое в любом строе требует так же всеобщего массового труда и “скученности”, 100% урбанизации
Вот вариант строя с почти полной роботизацией - не требует. Потому что работают роботы, толпы человек в одном месте там не нужно и можно от скученности сбежать. Можно, кстати, представить роботизацию и в чистом виде, без разных интеллектов - просто все роботы на телеуправлении а все работники "удаленной работой" занимаются.
На четвёртой разве что сменить уже существующий могут.
Ну так я именно про это. "У нас гадость получилась, под которую средств разработки нет и которую месяц новички учат. Давайте какой-нибудь LUA или вариант Python возьмем."
Одна из движущих сил цикла, кстати, которая в статье, вроде бы, не затронута - страх перекомпиляции. Нужно поведение объекта(или даже не объекта) изменить? Можно тупо код подправить. Но нет, обязательно все вынесут в конфиг. Потому что перекомпилировать и перезапускать приложение (или, еще хуже, большую систему) - долго и утомительно. А на пользовательской стороне часто вообще невозможно.
"Любой язык конфигурирования стремится стать тьюринг-полным языком программирования." (с) Не знаю чей
А где же ответвление от четвертой стадии? Который "Если у нас все равно язык программирования получился, то давайте возьмем не тот, что у нас получился, а какой-нибудь из существующих"? Или я плохо читал и в статье такой вариант тоже описан?
Ну как бы да. В мои определениях. Почему нет-то? Тут, правда, можно отговориться, что бесчувственное тело (например, спящее), ничего не хочет, но все равно это делает, поэтому это уже вообще рефлекс.
не в каждой культуре присутствует вот это “желание вкусного” как поведение при стрессе или скуке.
Это - возможно. В вот "желание съесть", когда это вкусное видишь (стимул такой) - что-то ну вот очень сильно сомневаюсь, что не присутствует. Но, как я замечал рядом - есть вероятность, что это "хочу" может быть не вшито в тушку, а быть выученным.
Но ведь на самом деле ведь и “желание тортика” оно совсем не врожденное, а обусловлено в том числе и представлениями в обществе о том, что вкусно.
А инстинктом тут предлагалось считать не "желания тортика". А "желание вкусного". А уж что вкусным с точки зрения конкретного экземпляра вида считается - может и разным быть.
С другой стороны: раз за разом(разные разработчики, разные продукты) оплачивать один и тот же функционал за счет госбюджета - тоже выглядит не очень хорошо.
Из занудства: или потребовать от производителя возможности устанавливать тот же месседжер, но в режиме "self-hosted"/закрытого контура. Никто же, вроде, требует, чтобы это именно одна инсталляция на всю страну была.
То что "многофункциональный сервис обмена информацией" == "Max" -- это отдельное распоряжение.
Насчет которого могут и передумать, если совсем халтурить. А желающие стать заменой - будут еще и всячески способствовать, чтобы это 'передумать' состоялось.
Так она не в его базе будет. А в чужой. (Смотрим на "Честный знак" и эквиваленты)
Желание производителей оказываться от своей же продукции, но проданной по 'серым' схемам немного задалбливает. Продукция ваша? Как "подделка"? А доказать можете что именно подделка? Ах нет... Значит - ваша, извольте обслуживать, даже если она до меня дошла через десяток промежуточных рук и три раза мир обогнула.
А если маршрут вам не нравится и его не должно быть - разбирайтесь как-нибудь сами со своими продавцами, а не с пользовтелем.
Причем сценарий, вроде, является стандартной практикой у разных туристов. Если вовремя не отметился - значит, проблемы и надо этим заняться.
Вот только при чем тут Госуслуги? Ей-богу, даже во всеми нелюбимый MAX этот функционал включить - и то больше смысла.
Правильно, это должна делать система сборки и, если возможно, рантайма. Скомпилировать исходник с константами - это доли секунды, так-то. А вот сделать так, чтобы они реально работать начали и это было быстро - ну, тут все систематически грустно.
Эти - просто про чистоту кода.
И потом что что бы программисты системы ни написали, менеджер (которому тоже права редактирования кода выдали) - все равно может библиотечными функциями работы с файлами пользоваться - на них же все публичные.
Я про что-то вроде этого (условный код, очень грубо)
После чего этот самый менеджер в своем коде может модулями работы с заказами пользоваться, с отчетами - и больше ничем.
А если попробует - его код просто не скомпилируется.
А если работает только с тем, что выдали - скомпилируется и успешно в очередную версию приложения автоматикой поставится.
После чего постепенно вообще все становится написанным на таком вот "менеджер мог сам расписать". Одновременно двигаясь в сторону, что на практике не может и не захочет.
Вообще, современным языкам, похоже, не хватает внятно оформленной концепции "единица компиляции/интерпретации с ограниченными правами". Чтобы эти самые менеджеры/пользователи могли сразу на целевом языке писать, но не могли написать лишнего.
Она не поможет, если код уже опубликован в распространяющей платформе, заверен разными подписями, проверен на 'не злит ли он антивирусы' и так далее. Если его менять - это же все заново проделывать надо. А конфиг - можно быстренько подправить и тот же самый бинарник его без всей этой бюрократии съест.
Это эквивалентно. Просто у вас "генератор C++ из... <что там у нас есть>" встроен невидимым для вас образом в компилятор (и эту часть тоже кем-то написана, "желательно без ошибок")
Да нет, выдумывают как раз люди, к программированию отношение имеющие. Только ползучим образом. "А давайте сделаем так, что вот сюда можно не просто значение вписать, а шаблон/формулу и будем его интерпретировать." - это так программисты мыслят. И "загоним логику в XML, превратив его в текст программы" - тоже.
Тут, правда, отдельным пунктом идет "визуальное представление логики", которое тоже все портит. Почему то считается, что "нормальному пользователю" легче понять эту лапшу коннекторов, чем просто текст.
Вот вариант строя с почти полной роботизацией - не требует. Потому что работают роботы, толпы человек в одном месте там не нужно и можно от скученности сбежать.
Можно, кстати, представить роботизацию и в чистом виде, без разных интеллектов - просто все роботы на телеуправлении а все работники "удаленной работой" занимаются.
Ну так я именно про это. "У нас гадость получилась, под которую средств разработки нет и которую месяц новички учат. Давайте какой-нибудь LUA или вариант Python возьмем."
Одна из движущих сил цикла, кстати, которая в статье, вроде бы, не затронута - страх перекомпиляции. Нужно поведение объекта(или даже не объекта) изменить? Можно тупо код подправить. Но нет, обязательно все вынесут в конфиг. Потому что перекомпилировать и перезапускать приложение (или, еще хуже, большую систему) - долго и утомительно. А на пользовательской стороне часто вообще невозможно.
"Любой язык конфигурирования стремится стать тьюринг-полным языком программирования." (с) Не знаю чей
А где же ответвление от четвертой стадии? Который "Если у нас все равно язык программирования получился, то давайте возьмем не тот, что у нас получился, а какой-нибудь из существующих"?
Или я плохо читал и в статье такой вариант тоже описан?
Ну как бы да. В мои определениях. Почему нет-то? Тут, правда, можно отговориться, что бесчувственное тело (например, спящее), ничего не хочет, но все равно это делает, поэтому это уже вообще рефлекс.
Это - возможно. В вот "желание съесть", когда это вкусное видишь (стимул такой) - что-то ну вот очень сильно сомневаюсь, что не присутствует. Но, как я замечал рядом - есть вероятность, что это "хочу" может быть не вшито в тушку, а быть выученным.
А инстинктом тут предлагалось считать не "желания тортика". А "желание вкусного". А уж что вкусным с точки зрения конкретного экземпляра вида считается - может и разным быть.
Вы слишком прицепились к тому варианту определения, которое именно про действие.
Последовательность желаний именно к такому результату, с действиями и будет приводить, если поверх еще контрольных механизмов не добавлено.
А если добавлено - то и многие неразвитые животные не будут делать, то, что инстинктом вроде бы положено, если их на эти попытки током били.